0

We've recently started using our own internal NuGet server to house packages that are common to many of our internal projects. Originally, every project we work on is versioned with the build date in the format:

[Year].[Month].[Day].[DailyBuildCount]

However, during our process to upgrade to .NET 4, we've decided to start versioning our packages with SemVer starting with v4.x. The problem is that NuGet treats the v4.x versions as OLDER than the ones versioned with the date format. In addition, projects referencing the v4.x versions think they need to upgrade to the versions with the date format, which aren't even targeting the same framework version.

Is there some way to configure NuGet such that package upgrades can't cross these versioning lines?

For inter-package dependencies, we have configured them with specific version dependencies such that dependencies themselves work OK. It's the main project reference that is the issue where "upgrades" may accidentally happen to an older version.

Sumo
  • 4,066
  • 23
  • 40

2 Answers2

1

Offhand, I think your best bet is to rename the packages slightly. That will cause them to be considered as completely separate packages and break the version chain altogether.

Eric Lloyd
  • 509
  • 8
  • 19
  • I had this thought before and now have no idea why I dismissed it. Do you have any suggestions on what to add to the name of the package to distinguish it given Microsoft's [naming rules](http://msdn.microsoft.com/en-us/library/ms229026.aspx) for namespaces (`.(|)[.][.]`). – Sumo Aug 30 '13 at 02:26
  • According to NuGet's [Package Conventions Page](http://docs.nuget.org/docs/creating-packages/package-conventions), the package name is an optional convention, so you could decorate it any way you like, as long as you're packaging against a `.nuspec` file. Assuming it's a company-internal package, you could just drop the `.` portion and be done with it. – Eric Lloyd Aug 30 '13 at 20:01
  • This is really about the only option. The `-safe` parameter helps with the `Update-Package` command to avoid upgrading too far automatically, but to really avoid any issues, it's best to choose a new package Id. – Sumo Sep 24 '13 at 03:35
0

I have a series of three blog posts that would help you:

The last link shows an example (in this case jQuery, but can be applied to any package) on how you can coerce the version to a specific range. This will ensure that when you issue an Update-Package command, the project is updated only with references that have a version between a minor and major value).

However, in your case probably the best solution would be as Eric Lloyd suggested before to completely break your dependency chain in order to keep a clean dependency structure.

byteflux
  • 226
  • 1
  • 6