Portable libraries and framework versions

Topics: General
Oct 8, 2012 at 8:34 PM
Edited Oct 8, 2012 at 8:35 PM

Hi, we have a NuGet package (CommonServiceLocator) which targets .NET 3.5 & Silverlight 3. We want to add support for newer frameworks by having a portable version of the assembly.

We added a new folder called portable-win+net40+sl40+wp to the NuGet package. This works well for example when using it from a Windows Store app. Nevertheless, if I have a .NET 4.5 desktop app, it still picks up the DLL from the NET35 folder.

Is there a way to specify that if the project is targeting .NET 4.0 or newer, that it should use the portable version instead? We'd like to discontinue the framework specific version in the future, in favor of the portable version, but we don't won't to leave people using older versions of the framework and/or Silverlight out by removing these entirely from the NuGet package.


Oct 9, 2012 at 6:21 PM

Unfortunately, this behavior is by design. NuGet prefers the specific framework folder over portable framework folder as long as it's compatible with the project, regardless of the version.

I agree though we should allow package authors to alter this behavior if they want to. We'll look into this in the next release.

I can't think of any work-around except splitting your package into two.

Oct 11, 2012 at 6:40 AM
Edited Oct 11, 2012 at 6:41 AM

Does this mean that net40 projects will also get the 3.5 version? This doesn't seem like an ideal behavior. The portable folder is indicating that it supports a later version then the platform-specific folder, just because an assembly is portable shouldn't rule it out in this case.

As a workaround Julian, you could just also put the portable binary in the net40 and sl4 folders (but leave the portable-win+net40+sl40+wp so that portable projects themselves can reference).

Oct 11, 2012 at 4:06 PM

Yes, correct. NuGet always picks the specific folder over portable one.

Oct 11, 2012 at 5:49 PM

Good idea davkean. Now that the landscape is more clear to me, I'll see the implications of each approach, and what it means for other packages depending on this one.

Thanks both for the help.