views:

857

answers:

4

(this is a .net build server)

I'm getting the following error:

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(1679,9): error MSB3091: Task failed because "LC.exe" was not found, or the .NET Framework SDK v2.0 is not installed.  

The task is looking for "LC.exe" in the "bin" subdirectory beneath the location specified in the SDKInstallRootv2.0 value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework. 

 You may be able to solve the problem by doing one of the following: 

 1.) Install the .NET Framework SDK v2.0.  

2.) Manually set the above registry key to the correct location.  3.) Pass the correct location into the "ToolPath" parameter of the task.

This is because we are using a component that requires LIC.exe to compile.

now I can solve the problem by installing the latest Microsoft SDK on the build server, but I thought the whole point of a build server is to not have your dev tools installed on it. I think I can probably solve this but not after some work figuring some things out (like these guys did)

http://richardsbraindump.blogspot.com/2009/07/some-teambuild-fun-and-games.html

should I install the SDK? and more importantly:

What is the primary purpose of a build server?

+5  A: 

The primary purpose of the build server is to build code. Anything that is needed to build the code needs to be on the build server.

John Saunders
A: 

I would say a build server needs to have everything needed to build; a TEST server may not have any SDKs installed.

Otávio Décio
This would make some sense also, however, we use ccnet, which runs NUnit tests along with the build. (if the tests pass then the build does too) Do you mean some sort of manual testing server?
KevinDeus
Different places call it different names - test, acceptance. An environment very close to production to make sure the system (including its installation) works without any supporting tool or SDK. NUnit tests would not be adequate on this environment but a front end testing maybe (such as Canoo WebTest for example)
Otávio Décio
+2  A: 

Your build server has to have all of your build/dev tools/libraries on it. That's how it's going to do the build.

So yes, install the SDK.

Simon P Stevens
Yeah, that would seem to make some sense, but then how do you deal with the old "No errors on the dev box, but there are errors on the deployment box" issue? It would seem to me that in this case that using this philosophy that you are just looking to build on another machine besides your own.
KevinDeus
also what happens if you upgrade up your toolset, and break a bunch of your builds (we have > 20 of them), is the time spent fixing it justifiable?
KevinDeus
The point of a build server is to keep your build environment constant. Developers PCs often change and have different library versions on them. By having a build PC, you know your builds will always be against the correct libraries and compilers. If you want to validate that your builds run correctly on a non dev box you need to be doing all your unit tests on a different machine.
Simon P Stevens
+3  A: 

The best way to do it would be to store everything needed to make builds in source control. When doing that you don't need to go through all your build servers when your build chain is updated, it will happen automatically. An added advantage is that you can go back in time and still be able to get everything built without needing to delve into all your old CDs to find the tools you need to build old versions of your product.

However, this might not be possible for all build tools. For example we tried to do it with Visual Studio 2005, but we got weird intermittent pdb errors from mspdbsrv when building from a non-installed tool chain. So unfortunately all our build servers all have VS2005 installed (but not the PS3 tool chain, which is really really nice since it's updated quite often).

Regards,

Sebastiaan

Sebastiaan Megens
You do PS3 development. Cool. How did you get into that? Are the compilers and libraries publicly available or do you have to sign agreements with Sony?
Simon P Stevens
I agree. I really do think that you need to keep all tools required for the build in Source Control. Keeping the tools in source gives the project a robustness that prevents chaos when it comes time to upgrade tools to a new version (and with the "going back in time" feature of source control, its far less likely to break a past build!MS does make it hard sometimes (such as its paradigm with LC.exe requiring a reg entry), however that can be taken care of in a build script, and is definitely worth the time spent scripting rather than bringing up and maintaining a separate Unit Test server
KevinDeus
not to say that separate test servers aren't required sometimes!but it certainly looks like in most situations that keeping a minimal toolset (like *just* the software to run the build) keeps things simple and gives you more options.
KevinDeus
@Simon P Stevens: the tools are very proprietary, but I work for Guerrilla Games, and we're part of Sony, that helps. :)
Sebastiaan Megens