MSBee, Team Build, VS 2003 Development

Topics: For MSBee Users
Aug 17, 2006 at 4:27 PM
migrated from power toy forums
originally posted by Scot Campbell

Here is the scenario,

We are migrating our .Net 1.1 applications to TFS,

Our developers will continue to use VS 2003 (using the the MSSCCI)
We would like to run builds on Team Build using MSBee
I want developers to build locally using the VS '03 IDE, so I believe that I need to have 2 copies of .sln and .vbproj files. One set left as v8.0 for VS '03 builds and one set upgraded to v9.0 for MSBuild builds on TeamBuild targeting .Net 1.1

How best do I setup the TeamBuilds builds? I currently have the upgraded .sln and .vbproj files checked-in the folder that holds the build type.

Should I change the build to use the upgraded project files or do I need to add a copy step to copy the updated build files to the build directory in a PreBuild event?

Aug 17, 2006 at 4:27 PM
originally posted by John DAddamio - MSFT

Hi Scot,

Yes, if you want developers to build in VS 2003 but use VS 2005 Team Build for your production builds, you will need 2 versions of the solution and project files. In fact, you will need them in separate directories or at least name them differently if you want them in the same directory.

The answer to your second question of how to set up the Team Build is your call. I don't see an "ideal" answer for this situation. If you maintain one version of the source files, you will need to modify both the 2003 and 2005 build procedures to insure that the correct copy of the solution/project files is used and that the project files can find the source code.

The obvious way to do that is to have the build procedure copy the solution and project files before the build.

I think I might try naming the solution and project files differently and leaving them in the same directory. Then the developers could use the "old" names and the Team Build woudl use the "new" names. This would avoid doing any copying or renaming during the build process and, therefore, you woudl have less risk.

If you're willing to maintain multiple source control code bases too, you just set up the Team Build to run in your VS 2005 production space and your developers work in VS 2003.

The drawbacks:

Trying to use one version (one source control "branch", I mean) for both builds runs the risk that the VS 2005 upgrade tool modified some of your code files during the conversion of the projects/solutions. This could lead to incompatibilities.

Having multiple "branches" of the projects under source control would mean that you occassionally have to synch them up to get the changes that your devs made in the VS 2003 version of your product. This might also require using the VS 2005 upgrade tool.

Personally, I would not do what you propose. I would have my developers work in VS 2005 and give them a little build script that uses MSBee from the command line. The drawback here is that they could not add new Windows Forms to a project easily. WinForms in VS 2005 uses partial classes which are unsupported in the VS 2003 compilers. The workaround is for the developer who needs to add a new WinForm to create a new project in VS 2003 and create the new form. Then, you upgrade the project to VS 2005 and incorporate it into the VS 2005 solution. Alternatively, they could do the work in VS 2005 and manually combine pieces of the partial class into a "normal" class so that VS 2003 compilers understand it.

Like I said earlier, there is no ideal way so it entirely depends on how you want your team to work and whether you want to use a single source control code base or maintain multiple source control branches of your code base.

Good Luck with your product! Let us know if we can help further.