Versioning where a package has an MVC dependency

Mar 30, 2012 at 10:43 AM

What is the recommended approach where you have a NuGet package that targets say MVC3 and then MVC4 is released?

If I understand correctly, leaving the package with a reference to MVC3 will allow both MVC3 and MVC4 users to use the package, as long as MVC4 users keep the binding redirects in place. This does mean that I cannot take advantage of any new MVC4 features but other than that, are there any more negatives with regard to relying on binding redirects?

If I change the package to reference MVC4 , MVC3 users will no longer be able to use the latest version of the package. Also, NuGet will suggest that anyone with an older version upgrade which will break their project if they are still using MVC3.

Would having two separate packages (one for MVC3 and one for MVC4) make any sense? This at least allows users to install the older version more easily than using the version argument with install-package.

Mar 30, 2012 at 1:16 PM

If you're referencing Mvc as packages ( it should really be no different from referencing any other package. As long as you can ensure that a major version increment of a package does not introduce any binary incompatibilities, you should be able to take a dependency on 3.0+ and it should just work.

Mar 30, 2012 at 2:08 PM

Interesting. I was not aware of the package.

Looking around at some popular packages that require MVC3, I cannot find any that actually use it. Is this the preferred approach going forward and should packages that are currently just reference the DLL be changed to have a dependency on this new package?

Mar 30, 2012 at 2:52 PM

I tried to use my Mvc3 package also with Mvc4 and there are issues...first of all the package start requiring full thrust(probably it detects an incompatibility and stop)...then when I changed the the settings in the config files to get full thrust, the application runs...but doesn't work. I think that if you interact in a tight way with the Mvc dll binary incomparibilities can occur..they are not so unlikely to occurr.

Since I don't like having too many packages, I am studying a way for the nuget package to "see" what version of the Mvc library is in the project, an then it choose whcih dll to install. However, this means customizing the package with powershell.... 

Mar 31, 2012 at 2:23 AM

The contents of this package should be identical to the ones that get installed as part of current and future VS templates. It shouldn't require any additional config than a regular (GAC?) reference to the Mvc binaries.

This package was released relatively recently and clearly isn't as popular as it needs to be (you had not heard of it!) which is probably why older packages aren't referencing it. But yes, taking a dependency on these packages would be the preferred approach going forward.