I'm comfortable with a "one-time" admin cost of up-front installation for a couple reasons.
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. 2. The setup.exe requires some user interaction anyway. It asks at least one or two questions that require end-user input. 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. I suppose we could get into a more detailed MSBuild or <msiexec/> scenario, but for now that's way-overkill for the type project we're doing. All that said, good to know about the <msiexec/> block. On Wed, Aug 17, 2011 at 2:34 PM, Brad Stiles <[email protected]>wrote: > Well, if you really need to install the applications, and it's > installed via an MSI, there is a command line for MSIEXEC, the MSI > installer program. Of course, the problem with having the setup as > part of your build is, if you can't figure a way to automatically > detect the presence, that you either need the uninistall as part of it > also, and/or deal with the cruft that MSIExec often leaves behind. > > If you determine that the applications actually need to be on the > server, then the one time upfront installation is probably the best > way to go, and then have that be a standard part of your build server > build up. > > On Wed, Aug 17, 2011 at 3:24 PM, Michael Powell <[email protected]> > wrote: > > That's another school of thought, yes. I'll visit with our 3D guy to > > determine whether that isn't easier. Otherwise, I'm just treating the > > dependency like a monolithic install. Its setup handles the hookups with > the > > (also installed) Visual Studio 2008 development environment. > > > > On Wed, Aug 17, 2011 at 1:16 PM, Brad Stiles <[email protected]> > > wrote: > >> > >> Do you actuall need those things on the build server, or do you just > >> need the libraries they install? If the latter, it might be easier to > >> include those libraries in your source control, so that no matter who > >> checks them out, they can build. > >> > >> On Wed, Aug 17, 2011 at 2:01 PM, Michael Powell <[email protected]> > >> wrote: > >> > For now, we'll just eat the "one off" administrative "cost" and > install > >> > it > >> > apart from the CI configuration. > >> > > >> > On Wed, Aug 17, 2011 at 11:31 AM, Michael Powell < > [email protected]> > >> > wrote: > >> >> > >> >> I have a feeling I know the answer, but I'll posit it anyway... > >> >> > >> >> We've got a build dependency in our VS2008 solution that I would like > >> >> to > >> >> automate if at all possible. Our solution depends on not only VS2008 > >> >> being > >> >> installed, but also XNA Game Studio 3.1, which we have included in a > >> >> generic > >> >> way in a tools\XNAGS\setup.exe file from our solution. > >> >> > >> >> I'd like to detect if this has been installed and install it as needs > >> >> be. > >> >> What makes it a bit trickier is that the XNA installer asks > questions; > >> >> in > >> >> other words, it is interactive. Not sure if there's a simple way to > >> >> bypass > >> >> the interactive installer... > >> >> > >> >> It's a chicken and egg type situation. Worst case we simply install > XNA > >> >> GS > >> >> sans the CC.NET build configuration and call it done. > >> >> > >> >> Regards, > >> >> > >> >> Michael > >> > > >> > > > > > >
