What is the equivalent property to use in msbuild for https://learn.microsoft.com/en-us/nuget/reference/nuspec#including-assembly-files for migrating from nuspec to msbuild for creating nuget package.
Related
I've created a simple .Net standard 2.1 logger nuget package containing serilog 2.10. The package work well when referenced has a project but fail with wrong serilog version when used has a nuget package with another projet.
I've tried downgrading to .Net standard 2.0 with no success.
I packed the project with the parameter -IncludeReferencedProjects but no luck.
Any ideas what I did wrong?
Thanks
I found a solution. I was using nuget.exe and it was not including dependencies.After trying many configs it didn't work. I ended using msbuild /t:pack and eveything is OK now.
I have two projects in my solution--one targets .net 4.0, the other targets .net 4.5. They both reference the same NuGet package which contains both 4.0 and 4.5 binaries.
How can I get NuGet to reference the same version--4.0--in both projects?
You can exclude the folder of the framework that you don't want to use (ExcludeAssets), and edit the PackageTargetFallback in your project.
In your project's csproj file:
<PackageTargetFallback Condition="'$(TargetFramework)'=='net45'">
$(PackageTargetFallback);net40
</PackageTargetFallback >
When referencing the package:
<PackageReference Include={package-ID} Version={version} ExcludeAssets="lib/$(TargetFramework)"/>
This way the package won't bring the binaries that you don't want, and the ones you want will be compatible.
Note: Taking dlls with a different target framework is not recommended.
I'm currently develop a set of libraries that progressively add more features.
For example, in my solution, I have a Foo project which defines some basic feature set, an additional project, Foo.Web, for web specific implementations and Foo.Web.Tokens for even more specific features. Foo.Web.Tokens depends on Foo.Web which depends on Foo.
I'm attempting to build separate nuget projects so a user only needs to reference those dependencies they need. I'm versioning the assemblies with GitVersionTask, so after build, they all get the same version number and I'm using the replacement tokens for nuget when building from a project so that the nuget packages all have the same version number.
My problem is that when I try reference a prerelease version of either Foo.Web or Foo.Web.Tokens nuget is unable to resolve the dependency on Foo. If, for example, I have published a 1.1.0.0-alhpa0001 package for each of the assemblies, when I try and update Foo.Web, nuget shows this error:
Install-Package : Unable to resolve dependency 'Foo (≥ 1.1.0.0)'.
Using the -Pre argument doesn't change this. A Foo.1.1.0-alpha0001.nupkg does exist but I feel like nuget won't resolve it because it's not a stable version, and I'm letting nuget automatically detect the dependencies from the solution using the following command:
.\.nuget\NuGet.exe pack source/Foo.Web/Foo.Web.csproj -Build -Version 1.1.0.0-alpha0001 -symbols -IncludeReferencedProjects
How do I properly allow the Foo.Web prerelease package reference the Foo prerelease package of the same version?
The IncludeReferencedProjects option seems to pull the version from the assemblyinfo.cs of the referenced project.
setting the AssemblyInformationalVersion attribute to the desired nuget package version seems to work as you want it to.
eg
[assembly: AssemblyInformationalVersion("1.1.0-alpha0001")]
I have a package and nuspec file that I build by copying the dll for the assembly in question into a lib folder which is in the same folder as my nuspec file. This all works fine and dandy, no issues here.
I have a second package which references the first via nuget so to build it's package I followed the same process but added in a dependency element into the nuspec file. When I do my copy from release to lib it also takes the dependent dll.
Since this is marked as a dependency can I remove this from by lib folder (I want it to be downloaded via nuget, not included in the current package).
I'm not sure I got your scenario exactly, but in general I could say: Depending on how you create your NuGet packages, you might not even have to specify the dependencies. Given a Visual Studio solution with the following structure:
* Solution1
- Project1
* projectfile1.csproj
- using external libraries through NuGet
- project reference to Project2
* nuspecfile1.nuspec
- Project2
* projectfile2.csproj
* nuspecfile2.nuspec
If you run nuget pack projectfile1.csproj, any NuGet packages included in Project1 will automatically be included as dependencies in your NuGet package, even if you haven't specified the dependency in your nuspec file. These dependencies will then also include the versions of the external libraries at the time of creation of the package.
As of NuGet 2.5, there is also a new feature to automatically resolve dependencies between projects in the same solution. With v2.5 you can run the following command:
nuget pack projectfile1.csproj -IncludeReferencedProjects
This will also result in a NuGet dependency to Project2. And in case Project2 isn't exposed as a NuGet package (i.e. it has no nuspec file), the Project2's dll will be included as a file in Project1's NuGet package.
After doing some testing it turns out that adding a dependency does not require the dll to be in the lib. The dependency assumes it will be resolved by Nuget. This can be confirmed by creating a new package file via the nuget GUI and adding a few dependencies. Note how they do not show up in the lib folder after save.
One of my libs has a dependency on System.Configuration but this .NET lib is not included by default in most of project types on Visual Studio. Is there a way to instruct NuGet Package Manager to add this .NET reference when installing my lib?
You can use the frameworkAssembly element in your package's nuspec file. This will cause NuGet to add a reference to the project when your package is installed.
<frameworkAssemblies>
<frameworkAssembly assemblyName="System.Configuration" />
</frameworkAssemblies>