I'm able to overcome this one. We're not the first, apparently. Our approach is to create a "Cruise" user (name as you will) with appropriate permissions (Administrators, beware!) and to setup the VS2008 environment for that user. The setup is basically to set the appropriate Tools \ Options \ Projects and Solutions \ VC++ Directories. These are user-specific and as long as the CruiseControl.NET service is also running under the same credential, we're good to go. After that, it's stupid stuff like internal project configuration stuff, unit tests, etc, that should be resolved prior to commits and such.
On Thu, Aug 18, 2011 at 3:38 PM, Michael Powell <mwpowel...@gmail.com>wrote: > Okay, that'll work. But how do we convey the Tools \ Options \ Projects and > Solutions \ VC++ Directories? Remember, we're using VS2008. Somehow we set > INCLUDE or other environment variables at what point in the build process? > Necessarily to what? For instance, we've got an entry > "$(SolutionDir)tools\boost-msvc90-pro" in our Win32 Include Files. Can that > simply be set in an INCLUDE environment variable in the same manner? i.e. > SET INCLUDE=$(SolutionDir)tools\boost-msvc90-pro ? > > > On Thu, Aug 18, 2011 at 3:32 PM, Rolando Valdivia < > rolando.valdi...@gmail.com> wrote: > >> A VisualStudio solution can contain c# and vc++ projects, you can build >> the solution using MsBuild. However it is not possible to build vc++ project >> directly with msbuild you always need a VisualStudio solution. >> >> Try "msbuild.exe yoursolution.sln /t:Rebuild /p:Configuration=Release" >> from Visual Studio command line. If that works, you can configure MsBuild >> task in your CruiseControl project with the same parameters. >> >> >> 2011/8/18 Michael Powell <mwpowel...@gmail.com> >> >>> Okay, I need to break it down what we've got, because I am somewhat at a >>> loss after doing a little reading as to how to proceed. >>> >>> Our solution is composed of mostly C# projects. There is on XNA project >>> which will necessarily reference the C# projects. At its core, however, is a >>> C++ boost-based VC++ project, which is throwing a monkey wrench into the >>> whole thing. >>> >>> In my reading, MSBuild.exe seems like the way to go in order to pick up >>> the majority of the projects in the solution. However, we need to convey to >>> MSBuild.exe the requisite INCLUDES and such in order for the boost part of >>> the VC++ project build to succeed. Everything else in the solution depends >>> on that. >>> >>> We are running VS2008 necessarily. Not in a place to upgrade to VS2010 >>> right now. Therefore, I am reading that VCBuild (?) might have been the >>> build tool for VC++? Which of course is being replaced by MSBuild now... Of >>> course... But that doesn't help us now. >>> >>> Any insights? Suggestions? >>> >>> Thank you... >>> >>> Regards, >>> >>> Michael >>> >> >> >
