Question

My team is experiencing an issue where when using Nuget for package management it creates references in my project to specific versions of a dll. Is there a way to stop Nuget from creating these tightly coupled references?

A bit of background.

We are using nuget to manage our internal shared libraries. Packages are normally installed using the VS UI. Nuget packages are created using nuget.exe spec and nuget.exe pack on the .csproj file.

We use a standard branching strategy of mainline dev is done on trunk and release off an rc branch.

We didn't want to enter into versioning hell by naming all of our packages x.y.z-build123 because a dev may need to do a local build away from our CI system and use that to test downstream solutions. Our answer to this was to simplify our package versioning by saying that all trunk builds are simply x.y.z-staging and then an rc build is named x.y.z This would enable a dev to do a local build and with the help of nuget.exe install pointing to a repository on the dev's machine use their build in downstream solutions. Without having to update packages etc.

The problem we are seeing is while this works fine at the package level. builds are failing as the references in projects are to specific file versions of an assembly. Which on a local dev build will not include a build number but on the CI server it will.

ie.

A project has a reference something like the following.

The build number part of the version (123) is different on the CI server to the local dev machine where it is usually 0.

Is there any way to get nuget to create version agnostic references eg just the assembly name rather than this almost strong name.

Was it helpful?

Solution

It appears that I have found the solution to this.

I created a new console project in an attempt to recreate the issue. Added the package that I was using originally and it was added without version information!

I could not see any odd settings on my previous project so started messing around. I was able to recreate the issue with the following steps. 1) add the nuget package to your project 2) build 3) uninstall the nuget package 4) reinstall the nuget package

This 4th step makes the package install into your project with version information.

What this all boils down to, is that if you have assemblies already in your bin folder and you attempt to add (or uninstall and reinstall) your new references will be added to the project with version information.

The solution is to make sure that you always clean your solution before dealing with nuget.

OTHER TIPS

Probably the trick can be made via binding redirects on the project.

But please consider that two NuGet packages with same id and version are considered the same package, and this is by design.

Consider this scenario:

  • You publish a package "foo.1.2.3-staging" from changeset 1
  • I install it in my solution
  • You publish a package "foo.1.2.3-staging" from changeset 2 (maybe it is a bugfix)
  • My NuGet will never notify the update and, worse, on every solution built on my machine it will keep using the old (cached) version

So you are forcing your developers to clear the NuGet cache every time they build a solution, just to make sure they are using the "real" version

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top