I have a .NET Standard library (1.4) VS 2017 project that contains custom MS Build task (MyTask) that need to be distributed via Nuget package (Let's say MyCustomTask.dll and it contains MyTask and Portable.targets that will be imported by target project)
This Nuget package with custom build task is then used by target .NET Standard (1.4) project cspro file to import the Portable.targets that invoke the Custom Build task.
However, at this point I keep on getting the build error
Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
I tried .NET Standard (1.4, 1.5 and 1.6) but same error.
The problem is that the consuming application, MSBuild.exe in this case, would need to include all the forwarding assemblies necessary to run netstandard tasks (e.g. depend on the NETStandard.Library).
The best solution in this case is multi-targeting the task library to a .net framework and a .net standard target framework:
<TargetFrameworks>netstandard1.6;net46</TargetFrameworks>
The idea is to have 2 dlls that will contain the task. In the project files contained in the NuGet package instead of using a dll path directly in <UsingTask>, the idea is to using a different dll file based on the $(MSBuildRuntimeType) property, which will be Core on the .NET Core version of MSBuild:
<PropertyGroup>
<_CustomTaskAssemblyTFM Condition="'$(MSBuildRuntimeType)' == 'Core'">netstandard1.6</_CustomTaskAssemblyTFM>
<_CustomTaskAssemblyTFM Condition="'$(MSBuildRuntimeType)' != 'Core'">net46</_CustomTaskAssemblyTFM>
<_CustomTaskAssembly>$(MSBuildThisFileDirectory)..\tools\$(_CustomTaskAssemblyTFM)\CustomTaskAssemblyName.dll</_CustomTaskAssembly>
</PropertyGroup>
<UsingTask TaskName="SomeCustomTask" AssemblyFile="$(_CustomTaskAssembly)" />
You can see examples of this in the asp.net core build tools and the .NET Core SDK.
Related
I've started a new .NET 7 project in Visual Studio 2022. The template I used was "ASP.NET Core WebAPI". The project turned out to look like this in the solution explorer:
I can see that there is a dependency upon a series of DLLs in the folder "C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.2\ref\net7.0". When I browse to this folder and grab, for instance, the "Microsoft.AspNetCore.Http.Abstractions.dll" assembly I see its version as 7.0.22..... which makes sense.
What is weird is that when I click "Manage NuGet Packages" on this project I see absolutely no NuGet package already installed. It looks like this dependency mechanism is something independent of NuGet.
Now I want to create a class library that will encapsulate some common functionality I'd like to share across the projects but it needs to read data from the HttpContext class, which is defined in the "Microsoft.AspNetCore.Http.Abstractions.dll" file. So how should I add this dependency?
Adding it through "dotnet add package Microsoft.AspNetCore.App" command on the class library projects seems like a waste of resources as it adds the entire bundle of dlls and I only care about .Http.Abstractons.dll and it's direct dependencies.
Plus, when I ran the command Visual Studio complained with the warning:
NETSDK1080 A PackageReference to Microsoft.AspNetCore.App is not necessary when targeting .NET Core 3.0 or higher. If Microsoft.NET.Sdk.Web is used, the shared framework will be referenced automatically. Otherwise, the PackageReference should be replaced with a FrameworkReference".
Adding the dll through NuGet worked as Visual Studio was not complaining any more but the version of assembly added was 2.2.0 and not 7.0.2 as in the dotnet package. So technically, the HttpContext referenced in one projects is a different thing to the HttpContext referenced in the other project.
Please help me understand this mechanism and how should I add the dll of interest to my project to be able to access HttpContext in my library.
When should I use dotnet add package and when should I use NuGet packages management? Any good reading on this subject to bring me up to speed from .NET Framework 4.+ to .NET 7 in this area?
As .NET user for the last 10 years or so I feel so lost in the recent developments and find official docs I can find on the web of little use.
I tried adding the Microsoft.AspNetCore.App package through the "dotnet add package" command - Visual Studio complained, plus it pulled the entire bundle of assemblies but I care about only "Microsoft.AspNetCore.Http.Abstractions.dll".
I tried adding the "Microsoft.AspNetCore.Http.Abstractions" NuGet package but the version of assembly added was completely different to the one referenced in the WebAPI project.
What is weird is that when I click "Manage NuGet Packages" on this project I see absolutely no NuGet package already installed.
Those dependencies are determined by the project SDK which can be found in the root element of .csproj:
<Project Sdk="Microsoft.NET.Sdk.Web">
...
</Project>
So how should I add this dependency?
For latest versions of .NET you should reference corresponding SDK via FrameworkReference, for example to reference ASP.NET Core components you should add <FrameworkReference Include="Microsoft.AspNetCore.App"/> to library projects .csproj file as mentioned in the docs (and in the warning):
<Project Sdk="Microsoft.NET.Sdk">
<!--... rest of file-->
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
<!--... rest of file-->
</Project>
In .net core 2.0 I add some nuget package.Project work in local but does not work in server-production.I click solution and click publih to folder and move that folder to server.But in published folder there is no this nuget dll
how can I publish that nuget dll?In that folder I didnt find that dll
C:\Users\HC.nuget\packages
I think the problem is all of those packages are included in the ASP.NET Core Implicit Store. These are only present however, if the SDK is present on the target machine. If this is the case you have 3 options.
Install the .NET Core SDK (not just the runtime) on the target machine. In this case the implicit store will be present.
Set the following property to false:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
This will cause the build to include dependencies that are in the implicit store so that the final published product only relies on the .NET Core Runtime and not the API.
Build a self-contained deployment
This will bundle everything (runtime and implicit dependencies) into your application.
Environment
Visual Studio 2017
.NET Standard 2.0
.NET Framework 4.6.1
MyCustomTask.csproj contains custom MS build tasks and has multi targets to generate a separate dll for .NET Full and .NEt Core runtime.
There is a 3 level dependency on the Nuget Package "Microsoft.Extensions.Configuration.Json" which in turn has a dependency to Newtonsoft.Json package. as shown below.
The build is all fine and the Nuget package for MyCustomTask is generated successfully.
When I install my MyCustomTask Nuget package on target project then the custom build task is getting successfully executed on .NET Full runtime from Visual Studio 2017, but for .NET Core dotnet build command fail to execute the custom build task...
System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral.
Even if I package all the dependent DLL and place it in same directory of the .netstandard custom task dll I keep getting same error.
Any thoughts how this can be resolved ?
Posting a solution here for those who are experiencing the same issue.
Credit to #MartinUllrich for posting the solution in a comment above. This saved me a lot of trouble.
https://github.com/AArnott/Nerdbank.MSBuildExtension
Ensure your custom task inherits from ContextIsolatedTask and copy the dependent assemblies to same directory as your task assembly.
We've recently migrated to Visual Studio 2017 Update 2. We have a .NET Core 1.1 app which targets .NET Framework 4.6.1 only, and has project references to .NET Framework class libraries in the same solution. We are using the 1.0.4 SDK version of dotnet.
One of the project references contains T4 templates which are configured to run on build. This requires importing Microsoft.TextTemplating.targets and related assemblies, so that the T4 templates can be transformed by MSBuild. These assemblies in turn require .NET Framework 4.6 assemblies (System, System.Data, System.Xml, etc).
Visual Studio 2017 has no problems building the code, however when we try to use dotnet build or dotnet publish in our TeamCity builds, the command fails with the following output:
c:\xxx\Microsoft.TextTemplating.targets(340,5): error MSB4018: The "TransformTemplates" task failed unexpectedly.
c:\xxx\Microsoft.TextTemplating.targets(340,5): error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.
c:\xxx\Microsoft.TextTemplating.targets(340,5): error MSB4018: File name: 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
Based on the research I've done so far, the .NET Framework references required to run the T4 transformation task are not being loaded by the dotnet CLI, but they are by Visual Studio, due to entirely separate MSBuild toolchains.
Is there any way to make dotnet publish work in the same manner as Visual Studio? This issue has completely broken our CI / CD trains.
NOTE: I tried including .NET Standard as a target framework to see if that might work, but we use several packages that are not compatible so that isn't an option (Entity Framework 6.1, for example).
The dotnet based commands run on a .NET Core build of MSBuild so it is unable to load full framework assemblies. If there are no .NET Core or .NET Standard versions of these assemblies, loading them during builds of the .NET Core version of MSBuild is impossible at the moment (this may become possible with the move to .NET Core 2.0).
In order to get CI/CD working, you need to use the VS version of MSBuild. dotnet publish only forwards to msbuild so you can get the same behaviour passing parameters to msbuild. For example:
dotnet publish -c Release
becomes
msbuild /m /t:Publish /p:Configuration=Release
With developing an custom MSBuild Task with Visual Studio 2017 RC, I have the following problem: As soon as I add other dependencies than just Microsoft.Build.Utilities.Core (using v15.1.0-preview-000458-02 for .NET Core Support), I cannot load the task into another .csproj MSBuild project as the dependencies are not found.
Is there a way to automatically copy all dependencies to the Debug folder?
Or do I have to publish it every time I want to test it?
Update1:
The problem with publish was something local to my environment and has been fixed.
Update2:
It seems that as soon as I change the TargetFramework from netstandard1.4 to netstandard1.6 it isn't even able to load the task at all. As soon as I use netstandard 1.6 it throws a an exception:
The task could not be loaded from the assembly.
Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies.
Is there a way to automatically copy all dependencies to the Debug folder? Or do
I have to publish it every time I want to test it?
By default and for good reasons, .NET Core and .NET Standard projects do not copy referenced assemblies into the build folder. Instead, they are resolved them from the NuGet cache.
But if you really need it, this behavior can be changed by overriding the default with the CopyLocalLockFileAssemblies setting.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Cref: https://github.com/dotnet/sdk/blob/d20405f91a2959fa91fea6285d9a896286727f2a/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.BeforeCommon.targets#L55-L56
Second question
It seems that as soon as I change the TargetFramework from netstandard1.4 to netstandard1.6
To build a task assembly that works on both "MSBuild.exe" and "dotnet.exe msbuild", you should target netstandard1.4 or lower. netstandard1.6 is not compatible with .NET Framework 4.6.1 (which MSBuild.exe runs on.)
If you need API not available in netstandard1.4, you will need to cross-compile your task for .NET Framework and .NET Standard, which is considerably more complex but can be done.