Add source files from the NuGet package to the project output directory

Question

I am trying to create a NuGet package for .NET assembly that runs pinvoke in my native win32 dll. I need to assemble both the assembly and the native DLL with the assembly added to the project links (no problem in this part), and the native DLL must be copied to the project output directory or some other relative directory.

My questions:

• How to pack native dll without visual studio trying to add it to the list of links?
• Should I write install.ps1 to copy the native dll? If so, how can I access the contents of the package to copy it?

Answer 1

Using the Copy target in the target file to copy the required libraries will not copy these files to other projects that reference the project, resulting in a DllNotFoundException . This can be done with a much simpler target file using the None element, since MSBuild will copy all the None files into project links.

 <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <NativeLibs Include="$(MSBuildThisFileDirectory)**\*.dll" /> <None Include="@(NativeLibs)"> <Link>%(RecursiveDir)%(FileName)%(Extension)</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </None> </ItemGroup> </Project> 

Add the target file to the build directory of the nuget package along with the required native libraries. The targets file will contain all dll files in all child directories of the build directory. Therefore, to add the x86 and x64 versions of the native library used by the assembler-controlled Any CPU , you will get a directory structure similar to the following:

• assembly
  • x86
    • NativeLib.dll
    • NativeLibDependency.dll
  • 64
    • NativeLib.dll
    • NativeLibDependency.dll
  • MyNugetPackageID.targets
• Lib
  • net40
    • ManagedAssembly.dll

The same x86 and x64 directories will be created in the project output directory during construction. If you do not need subdirectories, then you can delete ** and %(RecursiveDir) and instead include the necessary files in the build directory. Other required content files can also be added in the same way.

Files added as None to the targets file will not appear in the project when opened in Visual Studio. If you are wondering why I am not using the Content folder in nupkg, because there is no way to set the CopyToOutputDirectory element without using the powershell script (which will only be run inside Visual Studio, and not from the command line, on build servers or in other IDEs and is not supported in project.json / xproj DNX ), and I prefer to use Link for files rather than have an extra copy of the files in the project.

Update: Although this should also work with Content , not None , an error appears in msbuild, so the files will not be copied for links to projects deleted by more than one step (for example, proj1 → proj2 → proj3, proj3 won’t get the files from the proj1 NuGet package, but proj2 will be).

Answer 2

I had the same problem when I tried to create an EmuCV NuGet package, including both managed assemblies and unmanaged shared lyrics (which should also have been placed in the x86 subdirectory), which had to be automatically copied to the assembly output file after each assembly .

Here is the solution I came across that relies only on NuGet and MSBuild:

• Place managed assemblies in the /lib directory of the package (the obvious part) and unmanaged shared libraries and related files (e.g. .pdb packages) in /build (as described in the NuGet Docs ).

• Rename all unsupported endings of *.dll files to something else, for example *.dl_ , so that NuGet does not moan from the alleged assemblies placed in the wrong place ("Problem: assembly outside the lib folder".).

• Add the <PackageName>.targets file <PackageName>.targets to the /build subdirectory with something like the following content (see description below):

   <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <AvailableItemName Include="NativeBinary" /> </ItemGroup> <ItemGroup> <NativeBinary Include="$(MSBuildThisFileDirectory)x86\*"> <TargetPath>x86</TargetPath> </NativeBinary> </ItemGroup> <PropertyGroup> <PrepareForRunDependsOn> $(PrepareForRunDependsOn); CopyNativeBinaries </PrepareForRunDependsOn> </PropertyGroup> <Target Name="CopyNativeBinaries" DependsOnTargets="CopyFilesToOutputDirectory"> <Copy SourceFiles="@(NativeBinary)" DestinationFiles="@(NativeBinary->'$(OutDir)\%(TargetPath)\%(Filename).dll')" Condition="'%(Extension)'=='.dl_'"> <Output TaskParameter="DestinationFiles" ItemName="FileWrites" /> </Copy> <Copy SourceFiles="@(NativeBinary)" DestinationFiles="@(NativeBinary->'$(OutDir)\%(TargetPath)\%(Filename).%(Extension)')" Condition="'%(Extension)'!='.dl_'"> <Output TaskParameter="DestinationFiles" ItemName="FileWrites" /> </Copy> </Target> </Project> 

The above .targets file will be injected when installing the NuGet package into the target project file and is responsible for copying its own libraries to the output directory.

• <AvailableItemName Include="NativeBinary" /> adds a new "Build Action" element for the project (which also becomes available in the Build Action drop-down menu inside Visual Studio).

• <NativeBinary Include="... adds native libraries hosted in /build/x86 to the current project and makes them available for a custom purpose that copies these files to the output directory.

  / li>

• <TargetPath>x86</TargetPath> adds custom metadata to the files and tells the custom target to copy its own files to the x86 subdirectory of the actual output directory.

• The <PrepareForRunDependsOn ... block adds a custom target to the list of goals that the assembly depends on, see the Microsoft.Common.targets file for more details.

• The CopyNativeBinaries custom target contains two copy tasks. The first is responsible for copying any *.dl_ files to the output directory when changing their extension to the original *.dll . The second instance simply copies the rest (for example, any *.pdb files) to the same place. This can be replaced by a single copy job and the install.ps1 script, which had to rename all *.dl_ files to *.dll during the installation of the package.

However, this solution still does not copy the source binaries to the output directory of another project, referring to the one that originally included the NuGet package. You will still have to reference the NuGet package in your "final" project.

Answer 3

Here is an alternative that uses .targets to to insert its own DLL into a project with the following properties.

• Build action = None
• Copy to Output Directory = Copy if newer

The main advantage of this method is that the embedded DLL is copied to the bin/ dependent projects folder transitively.

See .nuspec file .nuspec :

Here is the .targets file:

 <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <None Include="$(MSBuildThisFileDirectory)\..\MyNativeLib.dll"> <Link>MyNativeLib.dll</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </None> </ItemGroup> </Project> 

Inserts MyNativeLib.dll as if it were part of the original project (but curiously, the file is not visible in Visual Studio).

Notice the <Link> element, which sets the name of the target file in the bin/ folder.

Answer 4

A little late, but for this I created a nuget package for it.

The idea is to have an extra special folder in your nuget package. I'm sure you already know Lib and Content. The nuget package that I created looks for a folder called Output and copies everything that is there into the project output folder.

The only thing you need to do is add a nuget dependency for the http://www.nuget.org/packages/Baseclass.Contrib.Nuget.Output/ package

I wrote a blog post about this: http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=6&mobile=0

Answer 5

If anyone else stumbled upon this.

.targets file_name MUST equal the identifier of the NuGet package

Everything else will not work.

Credits go: https://sushihangover.imtqy.com/nuget-and-msbuild-targets/

I should have read in more detail, since it was actually noted here. Took me alone.

Add custom <PackageName>.targets

Answer 6

There's a clean C # solution, which I find pretty easy to use, and I don't need to worry about NuGet limitations. Follow these steps:

Include the source library in your project and set the Build Action property to Embedded Resource .

Paste the following code into the class where you PInvoke this library.

 private static void UnpackNativeLibrary(string libraryName) { var assembly = Assembly.GetExecutingAssembly(); string resourceName = $"{assembly.GetName().Name}.{libraryName}.dll"; using (var stream = assembly.GetManifestResourceStream(resourceName)) using (var memoryStream = new MemoryStream(stream.CanSeek ? (int)stream.Length : 0)) { stream.CopyTo(memoryStream); File.WriteAllBytes($"{libraryName}.dll", memoryStream.ToArray()); } } 

Call this method from the static constructor as shown below UnpackNativeLibrary("win32"); , and he will unzip the library to disk shortly before it occurs. Of course, you must be sure that you have write permissions to this part of the disc.

Answer 7

I cannot solve your exact problem, but I can give you a suggestion.

Your key requirement: "And do not need auto-registration links" .....

So, you will need to familiarize yourself with the "solution elements"

See here:

Adding Solution Level Elements in NuGet

You will need to write voodoo with powershell to get a copy of your native DLL into your home (again, because you DO NOT want the link fire to be added)

Here is the ps1 file I wrote ..... to put the files in a third-party link folder.

There is enough for you to figure out how to copy your native DLL into some kind of "home" ... without having to start from scratch.

Again, this is not a direct hit, but better than nothing.

 param($installPath, $toolsPath, $package, $project) if ($project -eq $null) { $project = Get-Project } Write-Host "Start Init.ps1" <# The unique identifier for the package. This is the package name that is shown when packages are listed using the Package Manager Console. These are also used when installing a package using the Install-Package command within the Package Manager Console. Package IDs may not contain any spaces or characters that are invalid in an URL. #> $separator = " " $packageNameNoVersion = $package -split $separator | select -First 1 Write-Host "installPath:" "${installPath}" Write-Host "toolsPath:" "${toolsPath}" Write-Host "package:" "${package}" <# Write-Host "project:" "${project}" #> Write-Host "packageNameNoVersion:" "${packageNameNoVersion}" Write-Host " " <# Recursively look for a .sln file starting with the installPath #> $parentFolder = (get-item $installPath) do { $parentFolderFullName = $parentFolder.FullName $latest = Get-ChildItem -Path $parentFolderFullName -File -Filter *.sln | Select-Object -First 1 if ($latest -ne $null) { $latestName = $latest.name Write-Host "${latestName}" } if ($latest -eq $null) { $parentFolder = $parentFolder.parent } } while ($parentFolder -ne $null -and $latest -eq $null) <# End recursive search for .sln file #> if ( $parentFolder -ne $null -and $latest -ne $null ) { <# Create a base directory to store Solution-Level items #> $thirdPartyReferencesDirectory = $parentFolder.FullName + "\ThirdPartyReferences" if ((Test-Path -path $thirdPartyReferencesDirectory)) { Write-Host "--This path already exists: $thirdPartyReferencesDirectory-------------------" } else { Write-Host "--Creating: $thirdPartyReferencesDirectory-------------------" New-Item -ItemType directory -Path $thirdPartyReferencesDirectory } <# Create a sub directory for only this package. This allows a clean remove and recopy. #> $thirdPartyReferencesPackageDirectory = $thirdPartyReferencesDirectory + "\${packageNameNoVersion}" if ((Test-Path -path $thirdPartyReferencesPackageDirectory)) { Write-Host "--Removing: $thirdPartyReferencesPackageDirectory-------------------" Remove-Item $thirdPartyReferencesPackageDirectory -Force -Recurse } if ((Test-Path -path $thirdPartyReferencesPackageDirectory)) { } else { Write-Host "--Creating: $thirdPartyReferencesPackageDirectory-------------------" New-Item -ItemType directory -Path $thirdPartyReferencesPackageDirectory } Write-Host "--Copying all files for package : $packageNameNoVersion-------------------" Copy-Item $installPath\*.* $thirdPartyReferencesPackageDirectory -recurse } else { Write-Host "A current or parent folder with a .sln file could not be located." } Write-Host "End Init.ps1" 

Answer 8

This is an old question, but now I have the same problem, and I found a twist that is a bit complicated, but very simple and efficient: create the following structure in the standard Nuget content folder with one subfolder for each configuration:

 /Content /bin /Debug native libraries /Release native libraries 

When you pack the nuspec file, you will receive the following message for each native library in the Debug and Release folders:

Problem: build outside lib folder. Description: assembly 'Content \ Bin \ Debug \ ??????. Dll 'is not located in the' lib 'folder and therefore it will not be added as a link when installing the package in the project. Decision. Move it to the "lib" folder, if necessary. refer.

We do not need such a “solution” because it is only our goal: the built-in libraries are not added as NET Assemblies links.

Benefits:

• A simple solution without cumbersome scripts with strange effects that are difficult to reset when removing a package.
• Nuget manages native libraries like any other content when installing and uninstalling.

Disadvantages:

• You need a folder for each configuration (but usually there are only two: Debug and Release, and if you have other content that needs to be installed in each configuration folder, this is either the way)
• Own libraries should be duplicated in each configuration folder (but if you have different versions of native libraries for each configuration, this is either the way)
• Warnings for each native DLL in each folder (but, as I said, warnings are issued to the creator of the package during the package, and not to the user of the package during the installation of VS)

Answer 9

Put this content folder

the nuget pack [projfile].csproj will do this automatically if you mark files as content.

then edit the project file as indicated here by adding the ItemGroup and NativeLibs and None elements

 <ItemGroup> <NativeLibs Include="$(MSBuildThisFileDirectory)**\*.dll" /> <None Include="@(NativeLibs)"> <Link>%(RecursiveDir)%(FileName)%(Extension)</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </None> </ItemGroup> 

worked for me