This sample shows a .NET Core project which can be packaged into a nuget package just using dotnet pack, and when restored in another project, it integrates in the msbuild pipeline. One of the great things about this sample is it creates a nuget package that integrates with msbuild on linux, mac and Windows. However, the custom build code doesn't have dependencies on any other assemblies.
How can I adapt this sample to use code that uses a dependency?
Here are my failed attempts:
Attempt 1
I added a package reference to Newtonsoft.Json and changed the code to do some JSON serialisation. However, in the project that uses the build nuget, when I do a dotnet publish, I get the following error:
error MSB4018: The "Zip" task failed unexpectedly. [C:\git\MSBuild-Features-With-Nate-McMaster\Video-2\1-NuGet\Web.csproj]
error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified. [C:\git\MSBuild-Features-With-Nate-McMaster\Video-2\1-NuGet\Web.csproj]
Additionally, if my project didn't already have a dependency on JSON.NET, adding the build nuget would unnecessarily add it.
Attempt 2
I used nuget.exe spec to create a .nuspec file. At the end of the file, I added:
<files>
<file src="bin\Release\**" target="build" />
<file src="build\**" target="build" />
</files>
However, both "dotnet pack" and "msbuild /t:pack" ignore the file, and nuget.exe pack fails with the error Unable to find 'bin\Release\0-WriteATask\bin\Release\'. Make sure the project has been built..
If I try nuget.exe pack Zipper.nuspec or msbuild /t:pack /p:NuspecFiles=Zipper.nuspec, they both fail with the message Value cannot be null or an empty string..
Attempt 3
I edited the nuspec to remove all of the placeholders that are normally calculated from the project (any string starting and ending with a $). Then, doing a nuget.exe pack Zipper.nuspec created a nupkg file, and the net46 folder contains Newtsonsoft.Json.dll, but the netstandard1.3 folder does not.
The way MSBuild loads a task assembly can make it tricky to load additional assemblies that you may depend on.
Typically, the easiest way to solve this is to ship a copy of your dependencies inside your NuGet package. But your dependencies alongside your task assembly file in the package. There may be some additional complications that require you to use AssemblyLoadContext or the AppDomain.AssemblyResolve event.
You can do this without a nuspec file by forcing MSBuild to copy your assemblies into the local build output, and then copying them into your package. Set CopyLocalLockFileAssemblies=true, and add the items to _PackageFiles
Here's an example of how to do that: https://github.com/madskristensen/BundlerMinifier/blob/3333b5c38289a247391966443370ee6f4a29bf26/src/BundlerMinifier/BundlerMinifier.csproj#L35-L47
Hopefully, this will be addressed in the future, https://github.com/Microsoft/msbuild/issues/1312, and the task assembly resolution will use the NuGet cache.
Try it with the 9.0.1 version of Newtonsoft.Json, it worked for me, all these dll load problems went away, and it still targets .NET Standard. Although I did copy all the dependencies next to the task dll, but with the 10.x version even that didn't help.
Related
For some reason GitHub Actions is not pulling in one Nuget package ConfigCat.Client but works fine for the remaining 20 packages. This is one solution with many projects. It works fine in VS Build as well as local msbuild command. I have another simple solution in GitHub Actions that works fine as well. I'm using a win-2019 server runner with .NET SDK 5.0. I get:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2203,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "ConfigCat.Client, Version=6.5.2.0, Culture=neutral, PublicKeyToken=d28b16a067d7bbe2, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
I'm running this (restore & build):
msbuild $env:Solution_Path /t:Restore /p:Configuration=$env:Configuration /p:RuntimeIdentifier=$env:RuntimeIdentifier
msbuild $env:Solution_Path /p:Platform="Any CPU" /p:Configuration=Release /p:UapAppxPackageBuildMode=SideloadOnly /p:AppxBundle=Always /p:PackageCertificateKeyFile=$certificatePath /p:PackageCertificatePassword=${{ secrets.Pfx_Key }}
Errors from log file (could it be related to processorArchitecture=MSIL?)
2022-08-28T03:05:23.6891561Z Primary reference "ConfigCat.Client, Version=6.5.1.0, Culture=neutral, PublicKeyToken=d28b16a067d7bbe2, processorArchitecture=MSIL".
2022-08-28T03:05:23.6894672Z C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2203,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "ConfigCat.Client, Version=6.5.1.0, Culture=neutral, PublicKeyToken=d28b16a067d7bbe2, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [D:\a\DataProduction\DataProduction\BigLebowski\Services\FeatureFlagService\FeatureFlagService.csproj]
2022-08-28T03:05:23.6896617Z For SearchPath "{HintPathFromItem}".
2022-08-28T03:05:23.6897448Z Considered "D:\a\DataProduction\DataProduction\BigLebowski\packages\ConfigCat.Client.6.5.1\lib\net45\ConfigCat.Client.dll", but it didn't exist.
I've also tried changing the Platform to x64 with the same results.
Any insight or pointers is greatly appreciated.
Thanks to Péter Csajtai for solving the problem. The project was using packages.config and not restoring the nuget package as a result. Adding the parameter /p:RestorePackagesConfig=true to the restore resolved the issue. See also this question.
There is an error System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Management, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'.I figured when the System.Management.dll is in the output directory, the error will be gone.
It is reference using NuGet but I couldn't get libraries in NuGet to be copied to the output folder. So I thought of adding the physical System.Management.dll file into my project and and reference it as assemblies (right-click project -> Add Reference -> browse to library) thenset 'Copy Local' to True. However, the dll still won't get copied over to the output folder.
The application is on .Net 6. Is there a reason behind why I can't copy this library like other?
A .NET6 project would normally use System.Management version 6.0.0.
The error suggests that there is another package in your project that explicitly depends on 4.0.0.
Without knowing the specifics of you projects, I suggest:
inspecting the build output for warnings about package version,
upgrading 3rd party packages in your solution.
Figured out I could copy nuget package references to output directory by setting this attribute in the project file
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Then the nuget referenced packages will be copied to the output directory.
How can I <Import> a .targets file that is included in <PackageReference>d NuGet package in a non-SDK-style web application project that targets .NET 4.7.2?
Background
The web application project is not an SDK-style project. It references a class library project in the same solution. This class library project is an SDK-style project. It has a package reference to Microsoft.Data.SqlClient version 4.1.0, which depends on Microsoft.Data.SqlClient.SNI.runtime 4.0.0. The latter contains native binaries which are automatically copied to the bin directory of the project.
The native binaries are not copied to the bin directory of the web application project. This is probably because of this:
SNI is the native C++ library that SqlClient depends on for various network operations when running on Windows. In .NET Framework applications that are built with the MSBuild Project SDK, native DLLs aren't managed with restore commands. So a ".targets" file is included in the "Microsoft.Data.SqlClient.SNI" NuGet package that defines the necessary "Copy" operations.
The included ".targets" file is auto-referenced when a direct dependency is made to the "Microsoft.Data.SqlClient" library. In scenarios where a transitive (indirect) reference is made, this ".targets" file should be manually referenced to ensure "Copy" operations can execute when necessary.
Recommended Solution: Make sure the ".targets" file is referenced in the application's ".csproj" file to ensure "Copy" operations are executed.
Source
Not sure what "built with the MSBuild Project SDK" means exactly, but I think my scenario qualifies.
Now I'm trying to implement the recommended solution, but I cannot get it to work.
What I did
Step 1: add package reference to Microsoft.Data.SqlClient.SNI version 4.0.0:
<PackageReference Include="Microsoft.Data.SqlClient.SNI">
<GeneratePathProperty>true</GeneratePathProperty>
<Version>4.0.0</Version>
</PackageReference>
I added <GeneratePathProperty> because of step 2 below. According to the documentation this should make a property available that can be used to refer to files in the package:
Sometimes it is desirable to reference files in a package from an MSBuild target. In packages.config based projects, the packages are installed in a folder relative to the project file. However in PackageReference, the packages are consumed from the global-packages folder, which can vary from machine to machine.
To bridge that gap, NuGet introduced a property that points to the location from which the package will be consumed.
Step 2: import the targets file:
<Import Project="$(PkgMicrosoft_Data_SqlClient_SNI)\build\net46\Microsoft.Data.SqlClient.SNI.targets" Condition="Exists('$(PkgMicrosoft_Data_SqlClient_SNI)\build\net46\Microsoft.Data.SqlClient.SNI.targets')" />
You can see that the package contains this targets file using the NuGet package explorer (link). The PkgMicrosoft_Data_SqlClient_SNI property is named according to the documentation (linked above) and based on their example:
MSBuild properties and package identities do not have the same restrictions so the package identity needs to be changed to an MSBuild friendly name, prefixed by the word Pkg.
Step 3: verify the tool versions on our agent:
MSBuild 16.11.2.50704 (installed on the agent C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin)
NuGet 6.1.0.106 (installed via a pipeline task)
According to the documentation linked above, these fulfil the minimum requirements (MSBuild 16 and NuGet 5).
Step 4: run nuget restore on our build agent and then build the project using the Azure DevOps MSBuild#1 task with msbuildArguments: '/t:Build'.
Step 4: collect output and publish as an artifact.
Outcome:
The SNI files are not present in the output. When building locally with MSBuild 17.0.0.52104 (installed in 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\bin') I do see the SNI files.
<Copy SourceFiles="#(sourceFiles)" DestinationFolder="$(destinationFolder)\"/>
This used to work fine for me in MSBuild 3.5. But since I've been trying to migrate to 4.0, MSBuild throws me this error.
The "Microsoft.Sdc.Tasks.Folder.Copy" task could not be loaded from the assembly Microsoft.Sdc.Tasks.dll. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
I've tried putting the UsingTask, but still in vain. Any ideas?
The reason is simple,
You install http://sdctasks.codeplex.com/ in .NET 2.0 GAC. So MSBuild 2.0 or 3.5 can load it successfully.
.NET 4 uses a different GAC, so MSBuild 4 cannot find what you install in .NET 2 GAC.
Therefore, you see an error message.
My advice,
Switch to MSBuild Community Pack as suggested by http://sdctasks.codeplex.com/.
Instead of adding an MSBuild extension assembly into GAC, you should put it into your dependency folder (such as lib), and add it to source control.
When modifying your project file (such as csproj), make sure that in <UsingTask> you use the assembly path to your dependency folder.
My open source project #SNMP uses Gendarme MSBuild extension, and I have been using the above trick for a long time,
https://github.com/lextm/sharpsnmplib/blob/master/SharpSnmpLib/SharpSnmpLib.csproj
I'm not able to build solution incrementally. I checked diagnostic log and I found that every project containing workflows are always rebuild because of this:
Input file ".NETFramework,Version=v3.5" does not exist.
Workflows are always recompiled, new temporary files are created and project is build again.
Building target "WorkflowCompilation" completely.
Input file ".NETFramework,Version=v3.5" does not exist.
Using "CompileWorkflowTask" task from assembly "System.Workflow.ComponentModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
Task "CompileWorkflowTask"
No files found with '.xoml' extension in the set of input files.
Generated temporary code file: C:\Users\Ludwo\AppData\Local\Temp\uwdnm5th.cs
Workflow markup validations completed with 0 errors and 0 warnings.
Done executing task "CompileWorkflowTask".
Done building target "WorkflowCompilation" in project "Delta.Workflow.Common.Merged.csproj".
Target "CoreCompile" in file "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets" from project "h:\Prj\R4x\M\CountrySystems\Delta\Common\Delta.Workflow.Common\Delta.Workflow.Common.Merged.csproj" (target "Compile" depends on it):
Building target "CoreCompile" completely.
Input file "C:\Users\Ludwo\AppData\Local\Temp\uwdnm5th.cs" is newer than output file "obj\Debug\Delta.Workflow.Common.pdb".
I'm building my projects using MSBuild 4.0. My projects are set to build with v3.5 TargetFrameworkVersion, unit tests projects are build with TargetFrameworkVersion set to v4.0. I tried to build it on different PC but the result is still the same. I also played with references in my projects. It seems to be like v4.0/v3.5 conflict, but I don't know how to fix it. Any ideas?
I found it. The root cause is wrong version of Workflow.targets file imported inside my workflow (.csproj) projects. Workflow.targets for .NET v4.0 was imported instead of v3.5. It should be related to projects upgrade from VS2008 to VS2010 I did some time ago.
I changed Workflow.targets Import from
<Import Project="$(MSBuildToolsPath)\Workflow.targets"/>
to
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.targets" />
Hope it helps someone...