I'm really new to NuGet and having all kinds of trouble with it. So the latest problem is that I generated a bunch of .nupkg files and put them in a shared folder on the network and then set NuGet up to look there for updates. So let's say in the folder I have:
Author.library.2.1.0.nupkg
Author.library.2.2.0.nupkg
Author.library.2.2.1.nupkg
I then found out that the target framework (.net) is different for some of my projects (under the same solution), so I generated new packages for each target:
Author.library.net40.2.1.0.nupkg
Author.library.net40.2.2.0.nupkg
Author.library.net40.2.2.1.nupkg
Author.library.net45.2.1.0.nupkg
Author.library.net45.2.2.0.nupkg
Author.library.net45.2.2.1.nupkg
Next I right-clicked on the solution and chose Manage NuGet Packages for Solution and then went to Online, pointed to the Installed Packages and was able to install each package to the applicable projects (.csproj files). But now when I open the NuGet Package Manager for the solution and click on Installed Packages, all I see is once instance of library. If I click on it, on the right I can see that it's pointing to the Author.library.net45 package, but I have no way of seeing the .net40 version of the library. So I can't add it to the .40 projects.
And lastly, what if I want some of the projects to point at an older version of a package. I know that I am suppose to be able to specify that in the packages.config file:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Author.Library" version="2.2.0" allowedVersions="
[2.0.0,2.3.0)" targetFramework="net45" />
</packages>
which should load anything above (and including) 2.0 through 2.3)
or
<package id="Author.Library" version="(,2.4.0" targetFramework="net45" />
which should load any version below 2.4.
So my main question is why can't I see the two versions of the package in the NuGet Package Manager? And also, how do I best limit the versions that will apply to a particular library.
It looks like you cannot see the different packages since they both have the same package id of Author.Library. This is based on what you have shown in your packages.config file.
Also I would not have separate NuGet packages just for assemblies that target different frameworks. Instead put them in a single NuGet package in their own lib directory (e.g. lib/net40 lib/net45). You can have multiple assemblies targeting different frameworks in the same NuGet package. NuGet will pick the best match when installing the NuGet package into the project. Also note that you can use a NuGet package that contains just .NET 4.0 assemblies with a .NET 4.5 project since the assembly is compatible.
The allowedVersions attribute in the packages.config file is the thing to use if you want to restrict the NuGet packages that a project can update to.
Related
I created a setup project using Microsoft Visual Studio Installer Projects (0.9.3, this is latest for Visual Studio 2019). After setup is executed it installs Nuget package assemblies that are different from the assemblies generated during build.
Why is it doing that and how can I make it to chose assemblies consistent with build assemblies?
My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2)
Build retrieves assembly from:
C:\Users\.nuget\packages\system.valuetuple\4.5.0\lib\net47\System.ValueTuple.dll
Install retrieves assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
While install based on 4.0.2 creates a concern but works, when I upgrade nuget package to version 4.6 (and assembly to 4.0.3) install switches to using assembly C:\Users\vgdev.nuget\packages\system.valuetuple\4.5.0\ref\net47\System.ValueTuple.dll
If you look closer, you will notice path above has \ref folder and it contains "reference" assembly. Reference assemblies are not meant to be installed and cause errors BadImageformatException.
The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?
Install retrieves assembly from: C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
Which way do you reference that package? I can only reproduce this issue when I add reference manually.(Right-click project=>Add reference=>Browse...) If you're doing so, please remove that reference, and add that reference back by Nuget Package Manager UI.
My application is for 4.7.2 framework. Typical example is
System.ValueTuple.dll (4.0.2). When I upgrade nuget package to version 4.6 (and assembly to 4.0.3)
I can only find it with latest 4.5.0 here. And I think it contains the assembly version 4.0.3 instead of 4.0.2.
(I guess something corrupts the process when VS recognize your assembly version cause in most machines it displays 4.0.3 while in one machine, it displays 4.0.2, quite strange...)
The build after Nuget package upgrade continues to pull packages from
the correct \lib folder and application works fine. So what I want to
do is to make installer work consistently with build. Any advice?
Cause of the issue:
This strange behavior may have something to do with Setup project. I can reproduce same situation and I found this issue only occurs when I use PackageReference format to manage nuget packages in my application.(.net 4.7.2)
PackageReference format is the new nuget package manage format after VS2017. I'm not sure if the Setup project fully support for it.
Here're two suggestions which may help:
1.I found this issue only occurs when using PackageReference format. So you can try using Packages.config format in your application. And I've checked the setup project can recognize this format well.
Uninstall all PackageReference format packages, and go Tools=>Nuget Packages Manager=>Nuget Package Manager to set the Allow format selection... to true.
Clean all nuget cache and click ok. After that delete bin and obj folders, then restart VS to add those packages back using Packages.config format.
2.If you continue to use PackageReference format. Try excluding the assembly from ref folder, and manually add that from lib folder by Add=>Assembly=>Browse.
Note: Since Setup project may not fully support packageReference format projects, actually I think #1 could be more suitable for your situation. And you can create a new simple project with packages.config format to check if the issue can be resolved by Packages.config format. Hope it helps :)
It seems that the root cause of the problem is the usage of the BuiltProjectOutputGroupDependencies target by visual studio setup projects instead of the ReferenceCopyLocalPathsOutputGroup target (see PackageReferences put ref instead of lib assemblies in the output group used by VS installer projects).
The proposed workaround is to overwrite the BuiltProjectOutputGroupDependencies target at the end in the project file of your main project:
<Target
Name="BuiltProjectOutputGroupDependencies"
DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
Returns="#(BuiltProjectOutputGroupDependency)">
<ItemGroup>
<BuiltProjectOutputGroupDependency Include="#(ReferenceCopyLocalPaths->'%(FullPath)');
#(ReferenceDependencyPaths->'%(FullPath)');
#(NativeReferenceFile->'%(FullPath)');
#(_DeploymentLooseManifestFile->'%(FullPath)');
#(ResolvedIsolatedComModules->'%(FullPath)');
#(ReferenceComWrappersToCopyLocal->'%(FullPath)')"/>
</ItemGroup>
</Target>
I am creating couple of .NET Standard 1.6 libraries that I want to publish as Nuget packages. They share a common libary that is a 3rd project in the same solution as the first two. The shared library has no value by itself, but I am assuming that if I want people to use both of these two libaries in the same project I should publish the shared library as a Nuget package as well. If I don't I am worried about multiple copies of the same shared library "colliding" or not properly warning when there are version mismatch issues.
Am I correct that the shared library needs to be a Nuget package as well? Is there a way to reference the shared library as Nuget package, but use is as if it was a project reference when developing / debugging the 2 main libraries in this solution? If I had to publish to Nuget.org and wait for the package be propagate through the Nuget.org system before using a changed version in a debug session that is REALLY going to slow down development. Note that these are .NET Standard projects. I found How to reference related projects in the same solution when Nuget packages are the required output but that doesn't seem to work with .NET Standard (getting errors during pack) and I am also not sure if .NET Standard not using nuspec files anymore also would cause a problem.
I am also not sure if .NET Standard not using nuspec files anymore also would cause a problem.
The .NET Standard still using .nuspec files, and using old school nuget pack and a .nuspec will resolve this issue.
As per document dotnet pack:
NuGet dependencies of the packed project are added to the .nuspec
file, so they're properly resolved when the package is installed.
Project-to-project references aren't packaged inside the project.
Currently, you must have a package per project if you have
project-to-project dependencies.
So, to include project-to-project references in NuGet packages, you need manually maintain a .nuspec file and add dependencies. You can refer to the Create .NET Standard packages with Visual Studio 2015 for detail info.
Besides, dasMulli has provided a simpler way to do this by involving adding and hooking up a custom target :
<Project>
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);IncludeP2PAssets</TargetsForTfmSpecificBuildOutput>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\testprivatelib\testprivatelib.csproj" PrivateAssets="All" />
</ItemGroup>
<Target Name="IncludeP2PAssets">
<ItemGroup>
<BuildOutputInPackage Include="$(OutputPath)\testprivatelib.dll" />
</ItemGroup>
</Target>
</Project>
The source code comes from: "donet pack" is not including project references
Ive made a small Application that will be published in a nuget package.
Additional to my C# code i made a little html UI for administrative purposes.
Now i would like this html files to be placed in the new Project Explorer if this is possible?
To build the package ive downloaded the CreateNewNuGetPackageFromProjectAfterEachBuild Package.
Would be nice if someone has an idea how i can solve this.
Best Regards
Andre
You can have content files in a NuGet package that are added to a project. This is documented in the NuGet nuspec reference documentation.
For NuGet version 2 you can use a files element with a Content attribute:
<file src="css\mobile\*.css" target="content\css\mobile" />
This will create a css\mobile directory inside the project when the NuGet package is added.
With NuGet 3 in Visual Studio 2015 update 1 the new recommendation is to use a contentFiles if you need to support the newer project types that use a project.json file. Note that the recommendation is that these files are immutable and are not to be modified by a developer.
<contentFiles>
<files include="any/any/images/abc.png" buildAction="EmbeddedResource" />
I am using NuGet to manage dependencies.
I created a fresh Git clone of my solution, and noticed assembly reference problems.
I have Enabled Package Restore and checked settings as suggested here, but I still have these yellow caution icons on various assembly references:
For example, I had previously added AutoMapper through NuGet, so why is it broken here, and why isn't it showing in my packages.config:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="bootstrap" version="3.0.0" targetFramework="net45" />
<package id="EntityFramework" version="6.1.1" targetFramework="net45" />
<package id="jQuery" version="1.10.2" targetFramework="net45" />
<package id="Modernizr" version="2.6.2" targetFramework="net45" />
</packages>
This usually means that the reference you have in your project refers to an assembly which cannot be found on disk. To correct this problem the most direct solution is to note which references exist, remove them, and then re-add them. Since you are using NuGet to manage dependencies your job is much easier, you simply need to:
Remove all NuGet Packages (using "Package Manager")
Remove any lingering broken assembly references throughout your solution
Re-Add NuGet Packages to all projects which need them (again using Package Manager)
Based on your description, it sounds as though some projects did not have NuGet packages added to them, and perhaps the assemblies were 'cross referenced' by a developer from the NuGet packages folder. This is a mistake. Instead the NuGet packages must be added to all projects which depend on the packages. (For example, you should never find yourself manually adding an assembly reference to AutoMapper, ever, because it is managed by NuGet for you.)
Sometimes there is a bug where these appear prior to a nuget fetch, and selecting the reference node in Solution Explorer will cause the overlay glyph (yellow caution symbol) to remove itself (meaning the reference was resolved post-load, usually by 'package restore'.)
This is most often caused by project authors creating incorrect/direct references to assemblies in non-standard locations, thus a package restore will not resolve the reference issues, and the references typically break after a package update.
HTH
I manually went and removed all references that had the yellow mark next to them and then added them back one by one. This way, they started showing up in packages.config too.
I think the reason they weren't showing in packages.config previously was because I turned on the [Restore nuget packages] option much later in development. Had I done this as soon as I started my porject, I believe they would have shown up in packages.config.
PS. I used the search on nuget's website to find out if the package was available on nuget, or if it was a framework assembly.
You need to reinstall all packages in a project using:
Update-Package -ProjectName MyProject -Reinstall
In Package Manager Console, select your Default Project
Then
Update-Package -reinstall
I am using Visual Studio 2010 and want to add NServiceBus to my project.
Whether I use the Package Manager GUI, or the Package Manager Console, after installing the NuGet package, the project does not contain any additional assemblies in the project References, and therefore cannot reference any of the NServiceBus classes from my code.
If I manage packages for the solution it says that the package is installed, and when I open the packages.config file it contains this line:
<package id="NServiceBus" version="5.1.2" targetFramework="net40" />
But there is no NServiceBus classes available to my application.
It seems like your project is .Net 4.0. NServiceBus v5 requires .Net 4.5