4

We have several different teams building C# applications with Visual Studio. When we want to share libraries across teams, we create nuget packages for the libraries and add them to a local nuget feed.

The process we use to package our libraries is very simple: we create a .nuspec for the library, and then run nuget on the project .csproj to create the package.

This results in a package that is specific to the .Net version (4.0, 4.5, 4.5.1) selected for the .csproj for the project. We've pretty much standardized on 4.5 to deal with this.

Many publicly available nuget packages provide simultaneous support for different library versions, and we'd like our packages to do the same to make it easy for each of our teams to select .Net versions appropriate for them. I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams.

So my question is: is there an easy/standard way of setting up a library project in Visual Studio so it produces a cross-version-compatible Nuget package?

Improve this question
1
  • 2
    It may seem like a wording nitpick, but I recommend rethinking the best practice mentality. Commented Dec 4, 2015 at 18:32

2 Answers 2

Reset to default
2

Not a direct answer to your question, I know this, but...

Why target multiple versions of the framework at all?

When NuGet installs a package that has multiple assembly versions, it tries to match the framework name of the assembly with the target framework of the project. If a match is not found, NuGet copies the assembly that's for the highest version that is less than or equal to the project's target framework.

Matching assembly version to the target framework of a project

What we've done is figure out what our lowest common denominator is, both for our libraries and our organization. In our case, we have some older apps still running on the 3.5 framework, so any NuGet packages we have that need to be available to any/all projects also target the 3.5 framework. However, we also have a few libraries that are only needed by some newer apps, these target 4.5 (both the projects and the libraries). This lets us leverage newer features.

If we find ourselves in a situation where an older app needs to reference a package that must reference the newest version to work, we bite the bullet and upgrade the project. However, for our libraries/packages, we always target the oldest version possible. Basically, the split is where we want/need to leverage Async/Await.

TL;DR: Don't target multiple frameworks. Target the lowest common denominator. It provides motivation to upgrade those apps lagging behind on 3.5 or 4. (Or, God forbid, 2.0...)

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

This sounds like excellent advice... but what is motivating us to support multiple versions is that when we open Manage Nuget Packages for a project in Visual Studio, it only shows packages for the project's .Net version; it does not show older packages. Is there a workaround for that if your package is targeted at an older framework?
Hmm... I'm kind of feeling like this answer isn't appropriate now that the question was migrated from Programmers to SO...
Anyway @antlersoft, if you can't do it through the GUI, you should be able to do it through the command line.
2

If you really need to support different framework versions, you will first have to create different configurations for each framework version (in your .csproj files), utilizing the configuration manager. Similar to the standard configurations "Debug" and "Release", or "x86_Debug" etc. you can add configurations by yourself like Release_Fw_40, Release_Fw_45, Release_Fw_451.

When packaging with Nuget, you can use the parameter 

   -Prop Configuration=Release_Fw_40

to choose which configuration you want to build, as described in the Nuget docs. There are also some hints how to automate the package builds, including support of different configurations.

Note that this will impose some additional effort for your library maintainers to manage those many configurations. It should be obvious that even if you provide a "Fw 4.5.1" version of your lib, you can only use Fw 4.0 features in the source code as long as you want to support a Fw 4.0 configuration. So make sure what you are trying is really worth the hassle.

I know in principle how to build a package this way-- but it involves moving files around to different folders and invoking the nuget packager at a lower-level. I don't know of a way to automate this in a way that could be picked up easily across our teams

I am not sure what you meant by this sentence, maybe I am telling you only things you already knew. But "moving files around to different folders" and "invoking the nuget packager at a lower-level" are things which can be very easily scripted. For such tasks, you can use simple Windows shell scripting or Powershell scripting, whatever you prefer.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.