Multi-Targeting Frameworks

Apr 21, 2011 at 12:35 AM

So i create a package:


User has a project that is targeting Silverlight 3 and installs my package, my Silverlight 3 version is installed into thier references. Then the user decides they want to upgrade their project to Silverlight 4, they right click on their project and go to properties and change framework version to Silverlight 4. myAssemly.dll is still Silverlight 3. How do I get it to automatically change over to myAssembly.dll Silverlight 4 version. The user then realizes they don't have the correct framework version of myAssembly.dll and has to uninstall MyPackage and go find MyPackage again and re-install. that is a lot of work just to swap framework versions there needs to be an easier way.

Apr 21, 2011 at 12:49 AM

That's kinda of a fundamental problem with nuget. Since references aren't resolved at build time you'd have to take the manual steps you suggested. Is switching target frameworks a common enough action that you're concerned about this?

Apr 22, 2011 at 7:14 PM

In Visual Studio if you change a project from Silverlight 3 to Silverlight 4 visual studio will update the references to to correct version, why should NuGet be different and not update them as well. This should not be an extremely common casue, but it will happen and should not be overlooked. If it is possible to have this functionallity then it should be there it follows the flow of visual stuido, but if its not possible then I will note that as something to be aware of when our clients bring it up. I just want to make sure I have a correct understanding of deployment using NuGet.

Apr 22, 2011 at 8:23 PM

We can definitely look at it the issue and remember we plan to have versioned content as well as as assemblies so its not just tweaking assembly references. You can file an issue for this.

Apr 22, 2011 at 9:28 PM
Edited Apr 22, 2011 at 9:31 PM

I understand the Upgrade package Scenario, We will always keep including previous framework versions for people who are not yet ready to move to the newest framework. Use Case would be. User has existing project in Silverlight 3, wants to use our API, but does't want to be forced to update the target framework to Silverlight 4. They then can add our API into there existing Silverlight 3 project and when they are ready to migrate that project over to Silverlight 4 then the proper assemblies will upgrade and they are not hassled to uninstall our package an then go search for it again and re-install it. Big win for user experience.