But remember how MSBuild is built into Visual Studio. And it's just XML like you all should be familiar with.
From: [email protected] [mailto:[email protected]] On Behalf Of Michael Powell Sent: Thursday, August 18, 2011 12:31 PM To: [email protected] Subject: Re: [ccnet-user] Re: Chicken and egg build dependency Sounds like we may be on an MSBuild track anyway. I'm trying to avoid much of that because that's just one more script we need to become knowledgable about, but like you said, if it's a matter of licensing what not, then plausibly we look into the targets and setup our MSBuild environment for the build. On Thu, Aug 18, 2011 at 7:36 AM, Brad Stiles <[email protected]<mailto:[email protected]>> wrote: > 1. Having it be part of the Svn solution is sufficient for now. Minimally, > we let the thing travel with the tools part of the project and let it be. If you're using a standard installation of Visual Studio for your developers, you shouldn't really need to do this type of thing. Installing Visual Studio components on a build server *may* require you to have a Visual Studio license for that server. This *may* be covered by an appropriate MSDN volume license, but you need to verify that with your compliance folks. Oftimes new Visual Studio project types are supported in MSBuild using new "targets" files and sometimes additional or modified assemblies. If you can discern (perhaps using an installation watcher program) what those changes are, you might be able to make just those modifications on your build server and eliminate the need to install either Visual Studio or any addins on the server itself. > 2. The setup.exe requires some user interaction anyway. It asks at least one > or two questions that require end-user input. Using the command line can often eliminate the user interaction entirely. Another option is to modify the MSI file itself to change the queried values to the ones you want. This requires tools you may or may not have. > 3. This adds a project type to the Visual Studio environment that is > required by one of the solution's projects. Definitely more than I want to > get into for any CI configuration concerns. If it's solely a matter of additional assemblies, that can usually be managed by source control, in your case, Subversions svn:externals capability. If it's a matter of targets in MSBuild build files, then you have a slightly different problem. Making those changes one time and forgetting about them is likely to be much easier. > All that said, good to know about the <msiexec/> block. To be clear, I was talking about using MSIEXEC.EXE, the program to which msi files are tied in Windows, not anything in NAnt or CC.NET<http://CC.NET>. Brad
