Question

I would like to have in my repository as tagged or submodules the different versions of .NET like is possible with other external products nunit, ninject, rhinomocks. ProjectX is created with .NET 3.0 and nunit 2.4.x Projecty is created with .NET 3.5 and nunit 2.5.x Project Z is created with .NET 4.0B2 and a preproduction release of nunit

I would like to do this to be able to make changes from a machine without haveing to make changes to that machine, like updateing it to the latest version of .NET if it isn t. If I want to change a 3.0, 3.5 or even 4.0B2 project on a machine that is still at 2.0 for example (maybe it s not mine nor do I have admin rights). I would like to checkout the project, the version of .net it requires (and other versioned libraries nunit, ninject, rhinomocks etc from the repository) make my change using Notepad2 or someother NON-Visual Studio editor (as VS would require an installation as well as the framework installed), run the build script and commit/push the changes. When that is done delete the checked out/cloned directories and files as if I was never even on that machine.

Background: My repository is composed of many smaller unrelated projects, not like just one huge web app/site. Why maintain versions of external libraries? Because I don t always want to update ALL projects at once. If I do there s a script for that. Every developer is a telecommuting consultant. Who knows what s on their machine? Who cares everything(except .NET framework) is pointed to through the build script. Maybe my machine dies and I need to use my grandmas. Maybe I m on vacation and someones code is broke (not mine obviously) and I need to use the hotels.

Answer 1

This is not currently a supported scenario. In order to accurately build a project of a given .Net flavor, you must have the corresponding .Net SDK (or in some cases just the redist) installed on the machine. There is no way to essentially check the .Net framework into source code control.

Answer 2

Not to pick nits, but wouldn t this mean they couldn t necessarily run the code they were building? And if so, wouldn t that be a bad idea?

Answer 3

This is not supported. MSBuild is shipped with the .NET Framework itself so if you want to build using MSBuild version X where X is (2.0/3.5/4.0) you need the corresponding .NET Framework version (or higher) installed on the machine doing the building.

Since you are concerned with permissions and running different versions of .NET you may be interested in the Lab Management piece of Visual Studio 2010 which is being released.

友情链接