What I mean by Runtime relinking is this:
It is a good feature in the most time.
However my project needs extra plugins to work. (The plugins are just .dll files and the project will access them with reflection.)
So will the relinking make some types or methods unusable for the plugins? How could I avoid the problem?
Solution has been found at https://aka.ms/dotnet-illink.
<PropertyGroup>
<PublishTrimmed>false</PublishTrimmed>
</PropertyGroup>
Related
Assuming I have packaged a .net application e.g. MyConsoleApp.nupkg and have it available in a source, how would I go about "installing" this to a folder, such that I can run it from this folder:
my-folder/MyConsoleApp.dll
my-folder/Newtonsoft.Json.dll
....Other references....
I have tried nuget install with packagesDirectory option, but this gives the familiar output in the packages folder e.g:
myconsoleapp/1.0.0/lib/netcoreapp3.1/MyConsoleApp.dll
newtonsoft.json/11.0.1/lib/netstandard2.0/Newtonsoft.Json.dll
newtonsoft.json/11.0.1/lib/netstandard1.3/Newtonsoft.Json.dll
newtonsoft.json/11.0.1/lib/net20/Newtonsoft.Json.dll
....Other references....
I imagine there is a msbuild target which copies the correct content out of the packages directory to a build directory - is there an easy way to use this?
I have tried using dotnet restore/build with variations of a .proj file using PackageReference which make no reference to a specific build target, but these have not worked:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="MyConsoleApp" Version="*" />
</ItemGroup>
<Project>
I don't want to make a MyDummy.csproj which references my console app (or asp.net core app) to achieve this because it doesn't seem very clean, and I'm worried about getting the SDK and <PropertyGroup> stuff compatibly correct.
I understand this may not fall under best practices, but I would like to see if it can be done in any case.
Background
I want to deploy a mesh of c# core libraries, applications and plugins such that they all use the exact same versions.
The libraries (core application framework) are referenced by the applications (web apis, background service workers) and by the plugins (dotnet-script with nuget references to the libraries). The plugins are in turn invoked by the libraries.
The plugins must reference the same library assemblies as loaded by the applications, yet are resolved as NuGet references at runtime, which avoids a long list of guessed references to System.Etc.Dll in the scripts and related runtime failures.
Installing the applications via nuget packages leads to an interesting way to get a single source of truth for all - the nuget source.
I've seen how dotnet-script manages to do it:
https://github.com/filipw/dotnet-script/blob/master/src/Dotnet.Script.DependencyModel/ProjectSystem/csproj.template
During the msbuild of a project that has packagereferences, you are able to get access to the list of references. This is similar to doing a full build of a dummy project, but looks likely the only way to do this as of now - nobody seems to want to answer so I'll leave this here!
I'm trying to create a .net core unit test project against framework 4.6.1 which tests an project dependent on Microsoft.SqlServer.Types (10.0.0.0). Prior to .net core I'd add an app.config file with the binding redirect. I've tried this but the binding redirect does not seem to be picked up when I run from visual studio. What can I do to fix the binding redirect?
If you reference Microsoft.NET.Test.Sdk >= 15.3.0 in your project it automatically turns on the required MSBuild properties, as Fabian says below. See here.
You can add the following settings to your .csproj file:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
Otherwise adding them to an app.config in the root of the solution, as Joao says, works too. Make sure you set its Copy to Output Directory setting to Copy always or Copy if Newer.
Referencing the NuGet package Microsoft.NET.Test.Sdk >= 15.3.0 (I used Microsoft.NET.Test.Sdk 15.3.0-preview-20170601-03) solved this problem for me. That package automatically turns on the MSBuild properties mentioned in #Mardoxx's answer.
(I got this info from Martin Andreas Ullrich at https://github.com/NuGet/Home/issues/5335#issuecomment-306318810.)
In my case none of the solutions mentioned above helped (even if the binding redirects are generated automatically or added manually, looks like these hacks are really not working anymore as #Joao suggested).
So I added the desired version of the package to my project, even if it is not used directly and this resolved the issue. I don't like this approach, but this was the only way working for me.
Hopefully this method can help others as well.
Need to render bundled scripts from one project into another project in MVC. Unable to use Scripts.Render since both are seperate projects. If I use <script src="relative path of bundled script"> it works but I'm not able to debug any more. Is there a solution ?
2 projects are in same solution? if so try to do file linking, then do bundle from link-files
will get you debug and production versions.
btw: any objective reason to have cross call for content files between projects?
I'm using the Subversive plugin for Eclipse/Flex and I can commit the files correctly, but I have to rebuild Data/Services each time and reconfigure return types for each, etc. Does Subversion not provide a way to check/in out Data/Services or must these be rebuilt each time?
If I understand your comment to your question correctly, then it seems to me that it's not a problem of Subversion/Subversive, but a problem of Flash Builder's code generator which is generating/overriding your customized return types.
Maybe there are some Flex project settings files that are not committed. That would explain why you need to rebuild Data/Services each time you open the project.
By the way, if you do commit the project settings files, make sure all the paths are relative paths, so that the project settings can be shared among several developers.
You might find value in this Adobe devnet article about Flex project settings
My partner and I had different local names for the project we were working on so we had conflicts with the settings file.
I have an ASP.net Web Site Project (.net 3.5). Currently all of the non-code behind code files (including Linq2Sql stuff, data contexts, business logic, extension methods, etc) are located in the App_Code folder.
I am interested in introducing Unit Testing (using nunit) in at least some sections of the project moving forward. Any Unit Testing that I would be doing would need to have full access to all of the code that is currently located in the App_Code folder. I have done some initial reading so far, and the consensus seems to be:
This will not be possible given my current setup
Unit testing requires referencing classes that are part of a compiled dll, and a Web Site Project by definition only compiles at run time.
In order to proceed, I will need to either convert my entire project to a Web Application, or move all of the code that I would like to test (ie: the entire contents of App_Code) to a class library project and reference the class library project in the web site project. Either of these will provide access to the classes that I need in compiled dll format, which will allow me to Unit Test them.
Is this correct? Or is there another way that I can Unit Test without restructuring/refactoring my entire project?
My shop has finally worked through an answer for this for our MVC project. And I want to share it as I chased a lot of dead ends here on StackOverflow hearing a lot of people say it couldn't be done. We do it like this:
Open the MVC folder "as a website, from local iis" which gets intellisense and debugging working properly
Add a unit test project that lives in our source controlled directory
Add a pre-build step to the TEST project, since we can't add one to a project that is open as a website. Imagine website is \FooSite and
our test project is \FooSite.Tests. The compiled app code will end up
in FooSite.Tests\FooSite_Precompiled\bin.
*
<Target Name="BeforeBuild">
<AspNetCompiler VirtualPath="FooSite" TargetPath="$(ProjectDir)\FooSite_Precompiled" Force="true"
Debug="true" /> </Target>
Add a reference to the FooSite_Precompiled/bin/App_Code.dll in your test project.
Boom that's it. You can have your cake and eat it too. Every time you click Build in your solution you call the aspnet_compiler.ext tool
on your website csproj (which does still exist) which is able, unlike
MSBuild, to compile app_code, and the Debug="true" allows you step
into the app_code.dll code when debugging your unit test. And you
only need to Build when you're running updated unit tests. When
you're looking at the effects of your change on the page, you just
Change Code/Save/Refresh Page since the app_code folder dynamically
compiles when called from your web server.
Your conclusions seem correct. I would vote for moving functionality into one or several class library projects, since that may open the door for reusing the same functionality in other projects as well.
We have this issue at my company (My boss doesn't like DLLs, some rubbish about versioning...)
We have two ways round it that we use frequently:
1) Get the CI tool to do the unit testing: We use TeamCity which has a pretty tight NUnit integration, and our solution builds quick enough (and has few enough tests) for this to be a valid option.
2) Manually precompile and unit test the resulting binaries: It's perfectly possible to run the ASP.net compiler / MSBuild from the command line (as if you were doing a 'Publish' build) and just unit test the resulting binaries.
However, if you have the option of segregating the code into binaries (class libraries) or just using a web application, I'd suggest that as a better alternative.
Should anyone find themselves implementing Brian's solution, here's a Website.targets file you can include in unit testing solution. It (re)compiles website only when App_Code changes. Just add something like
<PropertyGroup>
<WebsiteName>MyWebsite</WebsiteName>
<WebsitePath>..</WebsitePath>
</PropertyGroup>
<Import Project="$(ProjectDir)\Website.targets" />
<Target Name="BeforeBuild" DependsOnTargets="CompileWebsite">
</Target>
to your .csproj, customizing WebsiteName and WebsitePath and you should be ready to go. Website.targets:
<?xml version="1.0" encoding="utf-8"?>
<!--
Target that compiles Website's App_Code to be used for testing
-->
<Project DefaultTargets="CompileWebsite" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AppCodeFiles Include="$(WebsitePath)\$(WebsiteName)\App_Code\**\*.*" />
</ItemGroup>
<Target Name="CompileWebsite" Inputs="#(AppCodeFiles)" Outputs="$(ProjectDir)\PrecompiledWeb\bin\App_Code.dll">
<AspNetCompiler VirtualPath="$(WebsiteName)" PhysicalPath="$(WebsitePath)\$(WebsiteName)" TargetPath="$(ProjectDir)\PrecompiledWeb" Force="true" Debug="true" />
</Target>
<Target Name="CleanWebsite">
<RemoveDir Directories="$(WebsitePath)\$(WebsiteName)\PrecompiledWeb" />
</Target>
</Project>
It looks like this is possible whilst still using App_code, but I would either move this logic out to its own class library project or change the project type to Web Application, as Fredrik and Colin suggest.
I always create my own ASP.NET projects as Web Application projects not Websites.
And as the OP stated it's also possible to move to a Web App project, which i would say is cleaner as well, your pages can stay in the wep app project, you will have them in 1 DLL (testable). All your business logic etc. goes in a separate class library / libraries.
It is possible to unit test classes stored in the App_Code folder without converting your project to a Web App or moving your classes to a Class Library project.
All that is necessary is setting the code files' Build Actions to Compile. This will cause Debugging and Unit Testing your website to output a .dll file.
Now when you reference your website project from the unit test project, the classes in the app_code folder will be visible.
NOTE:
Setting your .cs files' Build Action to Compile will cause your website to generate a .dll file on debugging and unit-testing. The .dll file will cause problems when you debug your website because IIS will now find your code in two places, the bin and the App_Code folder and will not know which one to use. I currently just delete the .dll file when I want to debug.
I had to change Brian White's solution by adding the PhysicalPath attribute. In addition I am not using the Default Web Site and had to change the VirtualPath property to my website name.
<Target Name="BeforeBuild">
<AspNetCompiler VirtualPath="myIISsitename.com" PhysicalPath="$(SolutionDir)MySiteFolder" TargetPath="$(ProjectDir)\MySite_Precompiled" Force="true" Debug="true" />
</Target>
The resulting dll will be at MySite_Precompiled\App_Code.dll