+2  A: 

We install the libraries on our machines (for the Visual Studio toolbox support), but also copy the binaries to our subversion repository:

/trunk/thirdparty/[company]/[software]/[version]

Once a new reference is added (as a result of dragging a new control to a form), we change the reference to point to the binary in the working copy instead. This means they are there on a full checkout working copy and are referenced by relative paths, which therefore works on the build server without installing the control libraries there.

It also allows us to build software that uses old versions of control libraries while new code written can use new ones.

Neil Barnwell
We do the same thing. We make it so that our repositories contain all the information necessary to make the build. No dependence on building on a special server.
Kevin
We have something similar. We get the 3rd party libraries from source control and put them to a network share from where they are referenced (sounds a bit complicated, but that's another story). This works well for free libraries. The problem starts when you have commercial dlls that process licenses.licx file. Any suggestions? BTW.: Valuable hint on versioning 3rd party dlls: NUnit for example has had some breaking changes even in minor updates so you badly need to be able to reference different versions.
The Chairman
This doesn't really address the question. The problem is specifically with the licenses.licx file.
bruceboughton
A: 

We always keep our 3rd party libraries in our source control system, so they get pulled down to the build server with the rest of the code. But, they are not installed on the build server so that will keep your IT happy. I don't know specifically if this works with your controls, but it works with ours. It keeps maintaining library paths and alike a lot easier as the directory structure is the same for everyone.

Alex
Getting libraries from SCM or refering them from a network share doesn't make much difference in this case. We already do something similar and it works well for free libraries. The problem starts when you have commercial dlls that process licenses.licx file. Any suggestions?
The Chairman
Unfortunately then, it seems you are stuck with getting your build server admin to install them on the build server. I understand the logic and reasoning of why they wouldn't want it installed. But, when you made the choice to use these, I think you made it necessary to install them on the server.
Alex
Your only other choice would be to contact infragistics and explain the situation and maybe they would have the answer.
Alex
So it seems to be an Infragistics-only-issue. The problem is, we don't have a platinum but a tin license. No immediate response on questions.
The Chairman
A: 

Our libraries are kept on the build machine (although a network share works just as well) and are copied to the output folder as the first step after getting all the source out of source control. MSBuild quite happily picks up the dlls from the output folder and this ways we also avoid having many binaries in the source control.

Pondidum
We already do something similar and it works well for free libraries. The problem starts when you have commercial dlls that process licenses.licx file. Any suggestions?
The Chairman
We haven't had a problem with that, we use several different pay for components, some of which want the .licx file, some want a .lic file in the appropriate directory, and one that wants a random file to be hidden in C:\Program Files somewhere.
Pondidum
@downvoter: why the -1 ?
Pondidum
A: 

This answer is taken from the comment by MusiGenesis:

Don't use licensed third-party control libraries; they just are not worth the hassle. If the Infragistics forum doesn't have a solution to this problem, then there is no solution to this problem.

The Chairman
@MusiGensis: If You make an answer out of Your comment, I will accept it and delete mine.
The Chairman
A: 

It doesn't really make sense to reduce your options so drastically just because of bureaucracy. It is completely ok for software companies to protect their code by distribution licenses and not to allow you to redistribute their sources along with yours. Providing installation package for sources that shows it's eula is normal way and everyone uses it, even microsoft.

I've got it you are using a setup where the continuous integration server and the build tools (agents) are running on the same machine.

How about expanding that solution and using more servers, or more virtual machines. Perhaps even a separate virtual build machine for each project? Then you should be able to install all the components you need for your build without disturbing the build of other projects.

easyCIS