Hi, I would like to ask some advice on setting up a source control structure. We've got an internal library project which is made in .NET 2.0. This library is used in many different projects (most of them 2.0) so it's very important to us.

Now with VS2008, we're starting to create new projects in .NET 3.5 / VS2008. Offcourse those projects are also using the library, but we cannot add the library projects since they're 2.0 (the conversion wizzard pops up asking to convert the project to VS2008). We can offcourse include the last released build DLL, but that's not ideal.

Is it possible, using Fortress/Vault, to create a Library35 folder with a VS2008 project in it? Offcourse it's a little more complicated than just copying, because changed made to the library code shoud ultimately be available in both libraries, except new functionality which uses the 3.5 Framework.

I don't exactly know how copying/sharing/branching could solve this, so I would like some help on this. Would it be best to convert the main project to 2008 and leave the sub library in 2.0? Or should I create a 3.5 sub project and leave the library as it is? I'm lost!

My initial response is to recommend that you try VS 2008's multi-targeting

http://weblogs.asp.net/scottgu/archive/ ... pport.aspx

We have a similar problem here, except we must stay compatible with VS.Net 1.1. We handle this by keeping two project files, VS 2003 and VS 2005. The code must remain 2003 compatible (which means we did not keep any code changes that 2005 did when it converted the project). We do two builds, one with each version of Visual Studio.

Yeah, but multitargeting only supports loading 2.0 projects in VS2008, not mixing 2.0 and 3.5 projects within one solution.

Your option of creating a second project file in VS2008 is a nice one which I didn't think of yet. Though I would like a source control solution even more, that does seem to be a good option. I'll just wait a bit for some more options

Let us know if we can answer any other questions.

lbauer wrote:Let us know if we can answer any other questions.

Well I would still like to know if Vault/Fortress provides any usable options for these kind of problems. The second project file seems like a good solution but that hasn't got anything to do with source control as far as I know (except for storing the file ofcourse)

If that is your question, then I can pretty definitively say no, Vault doesn't have a magic bullet that will make this problem go away for you. But we do feel your pain. When we release the next major version of Vault, different pieces will need to be tied to 1.1, 2.0 and 3.5. It's not a fun time.