Targeting multiple versions of the .NET Framework with the same source files

by noonand7. December 2012 16:09

I had a contract recently where I had developed a site in v4.0 of the .NET Framework and when it came time to deliver it I discovered that the target server only ran v3.5. Upgrading it was not possible unfortunately so I had to recompile the solution for v3.5.

Now, I had moved all of my shared libraries to v4 of the Framework the minute that Microsoft had issued a go-live licence in the beta stages as there were some key things I wanted to take advantage of in the new version. I had happily used them since then with no issue until this project.

I knew that a lower version of the Framework could not consume assemblies created by a higher version (the other way around works flawlessly in my experience) so how was I to get my newly downgraded website to talk to my shared libraries? The options I saw here were as follows:

  • I could create a once-off build for this customer but if there were support issues afterwards there would be a lag while I recreated these as well.
  • I could branch in TFS but my experiences of branching are, to be honest, not terribly positive.
  • I could somehow create a side-by-side project where I'd be able to produce v3.5 assemblies in tandem with v4.0 assemblies. This seemed like the best option for me and this is how I did it.

(You may have an automated way of doing this, but I only automate if I have to do something more than once and in this case I didn't envisage that)

  • Begin by copying all of the C# project files in the solution to new files. Explorer will give those new files names like My.Csharp.Project – Copy.csproj.
  • Rename them so they are identifiable as what they are going to be. I used the following convention: My.Csharp.Project.v3.5.csproj
  • Open your solution and rename the files that are in there using the same naming convention so they become My.Csharp.Project.v4.0.csproj
  • Now add the v3.5 projects into your solution, if you've named them correctly they will alternate with their v4.0 counterparts
  • One by one do the following with the v3.5 projects
  • Change the compilation version to v3.5 of the Framework
  • Change the output folders for the build versions (Debug and Release). The convention I used was:
    • bin\v3.5\release
    • bin\v3.5\debug
  • Optionally add a compiler directive (I used NET35) to the project which will allow you create version-specific code
  • Following on from c. above I added a line to my AssemblyInfo.cs file to output a different version numbers for v3.5 vs. v4.0 assemblies

    #if NET40

    [assembly: AssemblyVersion("4.0.*")]

    #elif NET35

    [assembly: AssemblyVersion("3.5.*")]



  • Now revisit your v4.0 projects and change their output folders as well. The convention I used was:
    • bin\v4.0\release
    • bin\v4.0\debug
  • If you're using source control you'll need to change your project GUID as well. Open the v3.5 project file in your favourite text editor and locate the line that looks like: <ProjectGuid>{GUID here}</ProjectGuid> to a new GUID


Add comment

  Country flag

  • Comment
  • Preview

Tag cloud