I think it comes with the framework. It's hard when development is based on VS 2010 though, not to flip your finger on the F5 key and get your solution built. I'm jus using that at this time in terms of development.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Brad Stiles Sent: Thursday, August 18, 2011 1:31 PM To: [email protected] Subject: Re: [ccnet-user] Re: Chicken and egg build dependency 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 > >
