Team System Builds and dropping an MSI

Hi,

I just started using Team System this week, and I've been able to muddle along fairly well, but I've just discovered something that to me is a real show stopper. And based on the searches that I have done in Google and in these forums, I'm beginning to think there is something fundamental I missing based on the small number of responses to this problem.

My problem is that the team system build does not build the Setup projects. I understand that this is because MSBuild does not support them, but I am flabbergasted by this fact. What use is a build system that does not create the fundamental deployment deliverable

Obviously Microsoft feels there is value, or Team System would not have been RTM'ed without this feature. That is where I'm stumped.

My existing projects and solutions all have setup projects within them, and my current build process builds these setup projects, installs them, and then runs the Nunit tests for that product. It then proceeds on to the next product/solution that depends on the previous build target, builds it, installs it, and runs the tests. And so on through all of the 8 or 9 solutions.

I think that my nightly build scenario seems reasonable, and I don't see how running the tests on the output executables and dlls in the drop directory even makes any sense since they won't run because the drop directory doesn't contain the files needed to execute the programs, let alone the log sources and performance counters, etc created by the custom install code.

So obviously I'm missing something fundamental or have taken a completely naive approach to team system.

Do I need to supplement Team System with my own hand crafted MSBuild script that handles my build and testing requirements

If so, since I'm completely new to MSBuild, can someone point me to examples of how to do this

Thanks for reading my rant
]Monty[

Visual Studio Team System32

Hello Monty,

You are right in your observation that MSBuild does not support building setup projects. But if you want to build these as part of the build process, what you can do however is that you can include a custom task to build these by calling devenv build on these(this is the command line for VS Build). Of course, this necessitates VS on the build machine though.

Now, in order to install this msi you have built you can simply include an Exec task in your AfterCompile target that installs the msi(s) that you have built during build process. Then your tests can proceed normally since installation is already done.

If you need more help with this specific scenario, please mail me on anutthar at microsoft dot com. I'll be glad to help you work this out.

Thanks for the reply, and I will be emailing you. :)

I just thought that since this is such a major omission, there would already have been some articles or sample code showing exactly how to work around this problem. Hence my plea for docs/examples.

]Monty[

For those who are trying to build .vdprojs, here's what I have added to the end of my team system build .xml file to get it to build my .vdproj's

This only works for a build script that has one solution. I haven't yet figured out a way to build the vdprojs when there is more than one solution per build project. It does support more than one configuration (like debug and release).

One point I'd like to make is that this is a bit more involved than just adding a <exec>...</exec> as has been suggested, because you need to account for multiple configurations (and solutions, but one step at a time)

EDIT: Whoops forgot the CreateProperty.

</ItemGroup>

<Target Name="AfterCompile"

Inputs="%(ConfigurationToBuild.Identity)"

Outputs="%(ConfigurationToBuild.Identity)"

>

<Output

TaskParameter="Value"

PropertyName="SolutionDir" />

</CreateProperty>

<Exec

Condition=" '%(SetupToBuild.Identity)'!='' "

Timeout="120000"

Command=""$(VS80COMNTOOLS)..\IDE\devenv.exe" " " /build " " /Project "$(SolutionDir)%(SetupToBuild.Identity).vdproj""

WorkingDirectory="$(SolutionDir)"

/>

</Target>

Wonderful, thanks for sharing your code, Monty. We will put up a blog entry explaining details on how to enable this for multiple solutions, multiple configurations etc.

For other readers of the post, we are following up with Monty via email and will post a short summary of the resolution.

I would also advice anyone who wants to integrate setup creation into the build process to have a look at WIX. I believe it is a much nicer way to create MSI setups than the build in Visual Studio solution.

http://wix.sourceforge.net/

Cheers,
David

Hi David,

I've heard good things about WIX and from what little I know, it sounds interesting. Are there examples of how to intregrate it into the Team System Build process to handle the msi files A custom MSBuild task perhaps

I don't think you can replace the entire build process with WIX (and still have the build labels, change tracking etc), but if there is a way or sample of how to use it within the Team System Build process, that would be great.

Thanks
]Monty[

Oh, I didn't want to imply to replace the build process with WIX!! I believe there are msbuild targets in WIX out of the box to create MSI files. It really is just a compiler to produce MSI files.

Cheers,
David

Gotcha. If I had went to the WIX site *before* I posted, I would have known that. :)

I've downloaded the wix tool kit, so I'll look for the MSBuild integration.

Thanks again
]Monty[

Well, I am a dummy :)

I just realized that the <AfterCompile> target won't work. Here's my explanation:
I create a build project that says compile solution1, then solution2, then solution3. Since solution2 depends on solution1, and solution3 depends on solution2, I need the process to look something like this:

Build solution1
Build/Install solution1 msi
Build solution2
Build/Install solution2 msi

Instead what you get using AfterCompile (assuming I added install) is:

Build solution1
Build solution2
Build/Install solution1 msi
Build/Install solution2 msi

So AfterCompile won't work. I need a DuringCompile.

I'm stumped again. :(
]Monty[

One possible workaround could be:

< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Add Solution1 to teambuild compile target (SolutionToBuild property in TfsBuild.proj)
Override AfterCompile target to install the msi generated by Solution1 and add an MSBuild task to compile Solution2 and so on.

Please refer Microsoft.TeamFoundation.Build.targets which is located at %ProgramFiles%\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild on TeamBuild machine for a sample of MSBuild task.

Hi,

Yes, I guess I could do that, but that's not really a general solution, and I'd be going down the 'just write my own dang build' road. :)

And if I were going down that path, before I did, I'd just stick a <DuringCompile> (or something) into the TeamFoundation.Build.targets CoreCompile target.

I think it might be easier to limit the build to one solution, do the msi creation and install at the end, and then do the next build, etc. Simpler overall.

One thing that is becoming very clear to me, is that Team system has a fundamental weakness in handling dependencies on other libraries. An easy way around this short coming, is to avoid the dependencies. I can do that by installing whatever libs my apps depend on on the build machine, and then use them as private assemblies. Which is probably a good thing anyway. Team system could never handle building my old system of .Net ServicedComponents all installed in the GAC (have to to be there to run as COM Services 'out of proc'). And without the beta web deployment project, it couldn't handle the SOA alternative either. I mean it doesn't even 'drop' the web sites for xcopy deployment.

Anyway, I think I've revised my overall approach to the distributed software I need to build. Use the Web Deployment project. Re-architect the app as a 3 tier system: Web UI hitting an SOA (Web Services) app layer. Nothing in the GAC, all actions originally done in MSI custom actions removed to an external utility, and try to go xcopy deployment all the way.

]Monty[

Thanks, Monty!

The only remaining question is how to avoid the

warning MSB4078: The project file "xxx.vdproj" is not supported by MSBuild and cannot be built.

Since the vdproj-file needs to be part of the solution, I see no way of getting rid of this warning (which obscures other, "real", warning). Any ideas

Thanks!

/F

Wait for the next version of Team System and hope they get a clue and support real-world deployment :)

]Monty[