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]>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. > > Brad >
