I have a product with multiple services that have many solutions each. In order to reference things across services we are using Nuget to download and reference the dlls. Since we are still in early development of this product there are a lot of changes to the core dlls and we are having a lot of merging issues and annoyances with updating the references.
I tried using Update-Package -ProjectName XProject -Safe thinking this would do exactly what I wanted it to, update all the references with the same Major/Minor version. However, it just skips over all the files saying they are updated. When I look in Nuget it clearly notices that there is a new version so I am unsure what the problem is...
No updates available for 'Framework.EntityModel'.
No updates available for 'Framework.Core'.
in packages.config:
<package id="Framework.Core" version="1.0.14030.1137" targetFramework="net45" />
<package id="Framework.EntityModel" version="1.0.14030.1137" targetFramework="net45" />
There are versions in nuget with the label: 1.0.14034.1137 so I don't know why it isn't picking them up. I can open up package manager and update from there fine. I just want a way to easily update every reference without doing things manually.
This is taken from the Versioning page of NuGet # the bottom of the page:
Dependencies are no longer unnecessarily updated during package installation
Before NuGet 2.5, when a package was installed that depended on a
package already installed in the project, the dependency would be
updated as part of the new installation, even if the existing version
satisfied the dependency.
Starting with NuGet 2.5, if a dependency version is already satisifed,
the dependency will not be updated during other package installations.
The scenario:
The source repository contains package B with version 1.0.0 and 1.0.2.
It also contains package A which has a dependency on B (>= 1.0.0).
Assume that the current project already has package B version 1.0.0
installed. Now you want to install package A.
In NuGet 2.2 and older:
When installing package A, NuGet will auto-update B to 1.0.2, even
though the existing version 1.0.0 already satisfies the dependency
version constraint, which is >= 1.0.0. In NuGet 2.5 and newer:
NuGet will no longer update B, because it detects that the existing
version 1.0.0 satisfies the dependency version constraint. For more
background on this change, read the detailed work
item as well as the related
discussion thread.
Edit:
The above explains why you may be experiencing your issue, but to actually help to resolve it, take a look at http://blog.nuget.org/20131216/update-all-experience-explained.html. It shows you how you could use the DependencyVersion parameter of Install-Package or override the default behaviour in your nuget.config file to use "HighestPatch".
See the Install-Package section of http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference for more information.
Related
When installing the two Nuget packages Hl7.Fhir.DSTU2 and Hl7.Fhir.R4, we get something like this:
The package DSTU2 seems to have issues using Hl7.Fhir.Support.Poco version 3.4.0.
If we install DSTU2 on it's own, all packages are using the version 1.9.0.
Is there a way in the .csproj file to specify sub dependencies versions and have the .dll installed in specific folders?
Here are the 3.4.0 versions .dll in my debug folder
Yes, you just add a PackageReference in your project for the transitive dependency as well. NuGet picks a single version to use for each package you depend on, and if you have a direct reference to a package then NuGet will always pick this version due to its nearest wins rule.
As you've spotted though, this can't be a lower version than any of your dependencies require themselves, or you get a package downgrade error. This is intentional - if you reference packageA which says it needs at least a particular version of packageB, then given that you can only use one version of each package it stands to reason that you need at least that version of packageB.
I have 2 solutions:
SolutionMyTool
SolutionToolUsage
From SolutionMyTool there are produced NuGet packages
MyTool 1.1.0
MyTool 1.1.1
MyTool ... (many, many new versions)
On SolutionToolUsage side I have dependency
<PackageReference Include="MyTool" Version="1.1.*" />
Now on each build of SolutionToolUsage I want to get the latest version of MyTool.
Is it possible?
It seems that SolutionMyTool on 1st buiod gets "latest version" of MyTool (eg. 1.1.7).
Then each next build of SolutionMyTool is using this version (1.1.7), although in the meantime there were produced newer versions of MyTool.
How can I always get the "latest"?
Thank you ;]
Just use an asterisk for the version.
The following line loads the latest version on every build.
<PackageReference Include="MyTool" Version="*" />
https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#floating-version-resolutions
EDIT
Maybe you have also to restore the project's dependencies with
dotnet restore
The command dotnet build implicitly restores packages.
As of 2020-January NuGet behaves like here.
If SolutionToolUsage has dependency
<PackageReference Include="MyTool" Version="1.1.*" />
Then on 1st build is taken newest version (eg. 1.1.2) of MyTool.
Then on each next build is taken this version (1.1.2) even if newer are available in NuGet Feed.
If you need "asked flow" the simplest workaround is to manually:
increase version of each MyTool with each lib build
setting explicitly this version in SolutionToolUsage
Although Microsoft sometimes "recommends" uninstalling and installing again MyTool.
https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages
Reinstalling a package during its development: Package authors often need to reinstall the same version of package they're developing
to test the behavior. The Install-Package command does not provide an
option to force a reinstall, so use Update-Package -reinstall instead.
When merging two projects, we're in need of Install-Package several 100 times. Doesn't Nuget support package restore, once Package.config is edited. The way it works like charm for Node JS package?
Once package.config is edited, why can't we fire Update-Package to
restore all packages?
Is it supported in the successor Dotnet CLI?
While packages.config tells NuGet which packages to download and extract (for which target framework), the process of installing package references may also modify the .csproj file. So if you update only one of these after a merge, you could find yourself trouble.
The successor of this mechanism is PackageReference (NuGet blog post), which replaces packages.config and only requires listing the referenced packages and versions (and even some additional MSBuild logic could be used by projects to manage shared versions / packages etc.). However, there is no migration tool available, so you'd need to uninstall all packages and add the package references you need. Some NuGet features also changes - for example the support fo content files (=> files copied into the project directory) was removed which may still be used by some projects (e.g. web projects assuming that jQuery or other JS libraries would be acquired in this way).
So I used to use the old packages.config method of installing nugets which worked by installing any dependencies when installing a package: i.e.
Package 1
Dependency 1
Dependency 2
I have now changed to use PackageReference but noticed as I was installing "Package 1" it would not automatically install the dependencies. As I wasn't sure I went and installed "Depdendency 1" and "Dependency 2" manually
Do I need to manually install "Depndendency 1" and "Dependency 2" when using PackageReference?
The direct answer to your question is simply no, you should not need to manually install the dependencies.
There have been a few changes and performance improvements in the recent VS 2017 and MSBuild work. There's some good information on what this means here:
In the past, if your project referenced package A, which in-turn referenced packages B, C and D, you would see all of them listed as your dependencies. With Transitive Package Restore, NuGet dynamically resolves dependencies giving you an uncluttered view of the packages you care about.
That explains the "missing" package references. If you're interested in the "missing" files themselves, there's more information on that too:
Solution-local packages folders are no longer used – Packages are now resolved against the user’s cache at %userdata%.nuget, rather than a solution specific packages folder. This makes PackageReference perform faster and consume less disk space by using a shared folder of packages on your workstation.
The reason I said should not need to is that there is a known issue around this area when mixing .NET Standard and .NET Framework.
I've got a class library that till today was for .NET 4.5, now I've been asked to port it to .NET 40 but I've got some difficulies. I've followed this approach
and it works for the nuget packages that
but using this approach I get an error when going to Manage Nuget Packages telling
What's the most clean way to target different .NET framework version without loosing nuget package manager?
UPDATE #1
I've this version of nuget package manager
The error message caused by the duplicate packages listed in packages.config file. Because the Manager NuGet Packages window will read the packages.config file to list installed packages in your project and manage them.
For your situation, please check whether the packages in your project could compatible with both of .NET 4.5 and .NET 4.0. If yes, you need not to use two version packages in one project. You just need to change the project .NET Framework through Project -> Properties -> Application -> Target Framework.
If the installed packages version could not compatible with .NET 4.5 and .NET 4.0 at the same time, and you still want to use the Manager NuGet Packages, I suggest you do with below manual operation: Comment out one version of the packages in packages.config file and then open Manager NuGet Packages. After using Manager NuGet Packages, please uncomment the version that commented before.