Yessir, I believe it's included. On Thu, Aug 18, 2011 at 11:31 AM, Brad Stiles <[email protected]>wrote:
> 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 > > > > >
