I've a custom NuGet package (My.Resources) containing an assembly and a dependency on another custom NuGet package (My.Base).
If I install the package, the installation finishes successfully, but the assembly reference is not added. Here is the full output from a Install-Packagecommand:
Attempting to resolve dependency 'My.Base (≥ 1.0.0)'.
Installing 'My.Base 1.0.0'.
Added file 'My.Base.dll' to folder 'My.Base.1.0.0\lib\net45'.
Added file 'My.Base.1.0.0.nupkg' to folder 'My.Base.1.0.0'.
Successfully installed 'My.Base 1.0.0'.
Installing 'My.Rsources 1.1.0-beta0001'.
Added file 'My.Resources.dll' to folder 'My.Resources.1.1.0-beta0001\lib\net45'.
Added file 'My.Resources.XML' to folder 'My.Resources.1.1.0-beta0001\lib\net45'.
Added file 'My.Resources.1.1.0-beta0001.nupkg' to folder 'My.Resources.1.1.0-beta0001'.
Successfully installed 'My.Resources 1.1.0-beta0001'.
Adding 'My.Base 1.0.0' to WindowsFormsApplication8.
For adding package 'My.Base 1.0.0' to project 'WindowsFormsApplication8' that targets 'net45',
>> Assembly references are being added from 'lib\net45'
Added reference 'My.Base' to project 'WindowsFormsApplication8'
Added file 'packages.config'.
Added file 'packages.config' to project 'WindowsFormsApplication8'
Successfully added 'My.Base 1.0.0' to WindowsFormsApplication8.
Adding 'My.Resources 1.1.0-beta0001' to WindowsFormsApplication8.
Added file 'packages.config'.
Successfully added 'My.Resources 1.1.0-beta0001' to WindowsFormsApplication8.
While we have several other custom NuGet Packages structured and build the same way, this is the only one with this behavior. The .nuspec inside the .nupkg looks fine and the assembly is in the correct (net45) folder.
NuGet is treating your NuGet package as a localized NuGet package that only contains language resources. Assemblies in this sort of NuGet package are not referenced.
If you rename your My.Resources.dll to something like My.Resources2.dll, for example, then NuGet will reference the assembly.
Basically any file that ends with .resources.dll is considered by NuGet to be a resource assembly will not be referenced when the NuGet package is installed.
Related
I used NuGet Package Explorer (for the first time) to create a .nupkg to share with others. I have one DLL that targets NetStandardLibrary 2.0,
But when I try to add the package I receive the following error:
Could not install package 'iCANMVCSDK 1.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
I thought that by using NETStandard 2.0 it could be installed in any .NET app. I also tried adding additional assemblies:
I rebuild, repackage, and I still get the same error. What am I missing?
I tried editing the project file like this:
<TargetFrameworks>netstandard2.0;net472</TargetFrameworks>
When I try to build after adding net472, I receive the following error:
The type or namespace name 'Http' does not exist in the namespace 'System.Net'
What really makes no sense to me is that I can add the DLL directly into the project (the one that targes NET 4.72) and it works as expected. The problem is when attempting to install it as a NuGet package.
I try to build and install nuget pack with c# proxy for c++ dll.
So, when I install my pack to target project with Visual Studio 2019, it seems, that install is success. But I not see my c++ dll copied from nuget content to in project folder.
My first version of nuget pack used build/Install.ps1, and it copied success my c++ dll to target project folder, but.. not for all projects. For example, when in VS2019 Nuget Package Manager I checked mark for target project with name like ProjectName - all is OK, Install.ps1 execute. But sometime projects in Nuget Package Manager have names like ProjectName\ProjectName.csproj - unfortunately, Install.ps1 not executed for such projects. This why I should to return to use targets files for copying.
Ok, I created target file, pack my nuget packet and install it with VS2019 Nuget Package Manager. C++ dll not copied, but, repeat, packet was installed success. This is content of installed packed in solution package dir:
- Comp.Dep.NetClient.2.3.1
- build
- netstandard2.0
- Comp.Dep.NetClient.targets
- Comp.Dep.NetClient.props
- c++.dll (need to be copy to target project folder)
- lib
- netstandard2.0
- c#.dll (client proxy, added to project references)
- Comp.Dep.NetClient.2.3.1.nupkg
I tried many kinds of Comp.Dep.NetClient.targets content. I try to use Comp.Dep.NetClient.props instaed. Nothing help :) dll not copied. Now, my Comp.Dep.NetClient.targets and Comp.Dep.NetClient.props has next content:
<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>
I used different kinds from this
https://qastack.ru/programming/19478775/add-native-files-from-nuget-package-to-project-output-directory
..and from this
How can I set the 'copy to output directory' property in my nuspec file?
..and others :) nothing work..
For example, my target project structure after install pack is next:
Solution dir
packages
Comp.Dep.NetClient.2.3.1
..(see structure on previous example)
MyApp.sln
MyApp (project dir)
MyApp.csproj
...other files, but not c++ dll
I expect that after install my nuget to MyApp project is success, my c++ dll will be copied to MyApp (project dir). But it not happens.
Why??!!
I want to create a NuGet package that copies the DLLs into a subdirectory of the output directory.
This is what the folder structure of my package looks like:
Package root
lib
net48
x64
First.dll
Second.dll
x86
First.dll
Second.dll
The DLLs should be copied to the respective subdirectory in the output folder as follows:
Output directory
x64
First.dll
Second.dll
x86
First.dll
Second.dll
I have tried the files attribute in the nuspec file:
<files>
<file src="lib\net48\amd64\*.dll" target="amd64\" />
<file src="lib\net48\x86\*.dll" target="x86\" />
</files>
When building the package the following warning appears for each DLL I use:
WARNING: NU5100: The assembly 'amd64\First.dll' is not inside
the 'lib' folder and hence it won't be added as a reference when the
package is installed into a project. Move it into the 'lib' folder if
it needs to be referenced.
Neither the subfolders are created nor the DLLs are copied into the output folder after I restored all packages.
How can I configure the nuspec file so that the DLLs are copied into the subfolders? Do I need an install.ps1 script?
I'm using .NET Core (and .NET 5) projects. And packaging one component with multiple project DLLs. Can do this by modifying prject files.
So if you also have .NET Core projects add the following section to your .csproj file (to the project which should be packaged) to package DLL, change the DLL names and path as you need it.
<ItemGroup>
<_PackageFiles Include="$(OutputPath)\First.dll">
<BuildAction>None</BuildAction>
<PackagePath>x64</PackagePath>
</_PackageFiles>
<_PackageFiles Include="$(OutputPath)\First.dll">
<BuildAction>None</BuildAction>
<PackagePath>x86</PackagePath>
</_PackageFiles>
</ItemGroup>
I have two projects
A.csproj
B.csproj
where B references A (reference to project in solution)
I want to automate creation of packages, where package B will contain dependecy to package A
I've generated nuspec using nuget spec A.csproj and created package using nuget pack A.csproj. The same for project B.
however B.nuspec does not contain dependecy to nuget package A?
I want to automate creation of nuget packages on TFS build server, where assembly version is determined at build time.
In package B, how to add dependency to package A with correct version?
Firstly, to add the referenced projects as part of the package, you need to use the IncludeReferencedProjects option.
The command line is something like "nuget pack A.csproj -IncludeReferencedProjects"
Secondly, as you want to create NuGet packages during TFS build process, you need to create one PowerShell script which is similar to the followings, and include the PowerShell script in the Pre-build script (Assume you're using TFS2013 or TFS2015).
$projectFile = "project.csproj"
$nugetPath = “NuGet.exe"
$version = $Env:TF_BUILD_BUILDNUMBER
Write-Host ("packing $projectFile...")
& $nugetPath pack "$projectFile" -Version $version -Symbols -IncludeReferencedProjects
I am currently trying to publish a load of nuget packages for all the projects in this solution. The projects are setup in a simple tree, with Myre being the base project and everything depending on it:
Myre <- Myre.Debugging <- Myre.Debugging.UI <- Myre.UI
Myre <- Myre.UI
Myre <- Myre.Entities <- Myre.Graphics
I'm trying to package up each separate project as a nuget package with the correct dependencies on the other Myre subproject packages as necessary.
My first step was to make a package for Myre (nuspec and bat file of process). This seems to work nicely, the gallery shows Myre as having a ninject (another nuget package) dependency and all is well.
The problem comes when I tried to make the next package. Myre.Debugging depends upon Myre (with a normal project reference) and nothing else. Using this nuspec with nuget pack (verbose) gives:
Attempting to build package from '(x86) Myre.Debugging.csproj'.
Packing files from 'C:\Long_Path\Myre\Myre.Debugging\bin\x86\Release'.
Add file 'C:\Long_Path\Myre\Myre.Debugging\bin\x86\Release\Myre.Debugging.dll' to package as 'lib\net40-Client\Myre.Debugging.dll'
Add file 'C:\Long_Path\Myre\Myre\bin\x86\Release\Myre.dll' to package as 'lib\net40-Client\Myre.dll'
Add file 'C:\Long_Path\Myre\Myre\bin\x86\Release\Myre.XML' to package as 'lib\net40-Client\Myre.XML'
Found packages.config. Using packages listed as dependencies
Id: Myre.Debugging
Version: 1.0.0.2
Authors: Microsoft
Description: Description
Dependencies: Ninject (= 3.0.1.10)
Added file 'lib\net40-Client\Myre.Debugging.dll'.
Added file 'lib\net40-Client\Myre.dll'.
Added file 'lib\net40-Client\Myre.XML'.
Successfully created package 'C:\Long_Path\Myre\Myre.Debugging\Myre.Debugging.1.0.0.2.nupkg'.
As you can see it picks up a packages.config file (presumably from Myre since there isn't one here) which it then determines a Ninject dependency from. If I wanted Myre.Debugging and Myre to be a single package that would be fine. However this is not what I want, I want Myre.Debugging to pick up a dependency on the Myre package.
How can I setup nuget to use Myre as a package reference and not simply to copy the Myre assemblies into the Myre.Debugging package?
Edit:: I tried not using -IncludeReferencedProjects and specifying:
<dependencies>
<dependency id="Myre" version="1.0.0.1" />
</dependencies>
But for some reason this just creates a package with no dependencies at all! Even if manually specifying dependencies like this did work, it's hardly ideal.
According to the NuGet command line reference for the Pack command, the IncludeReferencedProjects switch works as follows:
Include referenced projects either as dependencies or as part of the package. If a referenced project has a corresponding nuspec file that has the same name as the project, then that referenced project is added as a dependency. Otherwise, the referenced project is added as part of the package.
In your case, Myre.Debugging.nuspec does not match the project file names: (x86) Myre.Debugging.csproj, etc. I suspect that you'll need to match up those file names to get that command line option to work.
Alternatively, if you want to get this to work with a <dependencies> element in your nuspec file, you may be facing another variant on the name mismatch problem. Your Myre.nuspec file defines its ID as follows:
<id>$id$</id>
The NuSpec reference says that the $id$ token is replaced by "The Assembly name." If it's talking about the name of the DLL (ignoring the extension), then I think the generated IDs will be (x86) Myre, etc. You might want to try hard-coding the ID temporarily just to see if that resolves the issue.
I haven't tried making these suggested changes, and I can't guarantee they will work, but I hope this points you in the right direction. Good luck!