0

When upgrading Visual Studio to a newer version, a new directory is created e.g. "Visual Studio 2013". I understand that that makes sense as we want to differentiate between code targeting different versions of .net. But since some projects use other projects as their dll's for some repeated code - this raises a question - should we copy everything and have everything separate for .net 4.0 from .net 4.5 or should we have one library that works for both (since 90% of the code will be the same) and only create a special library for code that can't run on 4.0?

Just suggesting doing "whatever works for you" is not a good solution - at the moment both look viable. If one of the options has some disadvantages, they might become apparent only after we have many internal links from solution to solution, and there's no real way to change all links at once - one must search for every one of them manually, hoping not to miss anything.

Since we're obviously not the first facing this question, I'd like to hear from those with experience in the matter. (or anyone else, of course.)

(Though there might not be a clear cut answer to this question, I hope it will be allowed here just as the highest voted question on this site is.)

Community
  • 1
ispiro
  • 115
  • 4
  • Your question is rather confusing - do your projects have a direct dependency from the VS installation directory? And if the answer is yes, why? Furthermore, are you aware that VS 2013 does support .NET framwork target versions from 2.0 up to 4.5? – Doc Brown Jul 09 '14 at 14:22

2 Answers2

3

The proper answer in 2014 is none of the above. First, that default file save location has no real meaning in life -- I suspect it is just Microsoft following their own rules about where programs should save things by default.

As for how to deal with cross-cutting dependency projects, the right answer is to treat them as projects in their own right with their own source control and build systems and leverage nuget to use them in other projects. If you can't hack that I would suggest letting each project keep a copy of the dependent DLLS (and sources if possible) so they stand on their heads.

Directly referencing build output like you seem to be doing creates some versioning nightmares to say the least. If that is your only option I would strongly consider just statically including the code in the project that is using it so it has it's own "library."

Wyatt Barnett
  • 20,685
  • 50
  • 69
1

A library which is created for .NET Fw 4.0 (or before, down to 2.0) should be (in most real-world cases) usable from any 4.5 project (the opposite is not true). So as long as there is no compelling reason to upgrade a library to .NET Fw 4.5, I would recommend to stay at 4.0, at least as long as you have at least one project which is 4.5 based which uses that lib. That strategy will allow you to have one library which works for both kind of projects, without the need for duplicating anything.

Note that you will not have to install an older VS version for maintaining the 4.0 lib - VS 2013 supports 4.0 as well as 4.5 projects, and it even does not enforce an version upgrade for projects files of older VS versions.

If you cannot avoid the need to keep a 4.0 version of a library under maintenance in parallel to a 4.5 version of the same lib, try to keep the changes to the 4.0 small, use an appropriate branching model of your version control system, and make sure you can transparently bugfix the 4.0 version while implement new features into the 4.5 version in parallel. But be aware that every bugfix for the 4.0 version will have to be merged into the 4.5 version as well, so you may generate some additional effort this way.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565