While it's true that Visual Studio uses MSBuild behind the scenes, MSBuild can be installed separately with the .NET Framework. It's been long enough that I don't remember, but it's either included with the framework, or at least some packages, or is available in a separate SDK download.
On Thu, Aug 18, 2011 at 12:55 PM, Katherine Moss <[email protected]> wrote: > 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]> > 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 > >
