How do you use commercial libraries in a continuous integration assembly?

Question

Customization

We use licensed Winform Infragistics controls to create desktop applications. All of our software assemblies are run on the CruiseControl.NET server.

Note Ignore the combination of Infragistics and CCNET - any other commercial library of .NET controls and any other CI server is likely to lead to the same situation. Edit : Referring to Andy's answer , this could only be a problem with the Infragistics function.

As I understand the terms of the Infragistics license agreement, you can use the licenses used on dev machines additionally in automated build environments (under certain circumstances). It's good!

But how? Recommendations presented at the Infragistics forum: "You need to install Infragistics components on the build server." This is bad, since the build server administrator does not allow me to do this. The administrators of the negative attitude towards server installations (except for the .NET SDK) are completely clear to me, since the need for reliable and reproducible builds on all machines requires the least complicated configuration (without updating the service pack-update-ping-pong).

Problem

To avoid Works-on-My-Machine-Pattern , all assemblies referenced by our projects are stored on a network drive and can also be found in the Infragistics library. This works well on developer machines with visual components installed. But, trying to create a project on the CI server without installing the Infragistics package, a license exception occurs:

LC0004: Exception occurred creating type 'Infragistics.Win.UltraWinEditors.UltraOptionSet, Infragistics2.Win.UltraWinEditors.v9.1, Version=9.1.20091.2039, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb' System.ComponentModel.LicenseException in licenses.licx(1, 0) 

Potential solution

If any lines related to Infragistics assemblies are deleted from the licenses.licx file, the project is built on the CI server without complaints. But I suspect that by fixing the file we can - without purpose - use some kind of trial version on the build server (and find pop-up messages or copyright watermarks after we released the software)

Questions

• What are your experiences with commercial libraries in a continuous integration environment?
• Is there a way to deploy licensed management libraries to the build server using XCOPYing?
• Can I omit the contents in licenses.licx and what are the consequences?

Note : Yes, I asked this question on the Infragistics forum, but I didn’t get any advice except “Install the management pack on the CI server.”

Answer 1

This answer is taken from a comment by MusiGenesis :

Do not use licensed third-party management libraries; they just are not worth the hassle. If the Infragistics forum does not have a solution to this problem, then there is no solution to this problem.

Answer 2

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

/ trunk / ThirdParty / [company] / [Software] / [version]

After adding a new link (by dragging and dropping a new control onto the form) instead, instead of linking to the link to the binary copy instead of the working copy. This means that they are on a full working copy of the check and refer to relative paths, so they work on the build server without installing management libraries there.

It also allows us to create software that uses old versions of management libraries, while new code can use new ones.

Answer 3

In fact, it makes no sense to drastically reduce your opportunities just because of bureaucracy. Software companies are perfectly okay to protect their code with distribution licenses, rather than allowing their sources to be redistributed along with yours. Providing an installation package for sources that show it, eula is the usual way, and everyone uses it, even Microsoft.

I have it for you. You have an installation where the continuous integration server and build tools (agents) work on one computer.

How about expanding this solution and using more servers or more virtual machines. Perhaps even a separate virtual machine for each project? Then you can install all the components necessary for the assembly, without disrupting the creation of other projects.

Answer 4

We always store our third-party libraries in our source code management system so that they are pulled to the build server with the rest of the code. But they are not installed on the build server, so your IT applications will be happy. I do not know specifically if this works with your control, but it works with ours. It continues to support library paths and is much simpler because the directory structure is the same for everyone.

Answer 5

Our libraries are stored on the build machine (although the network share works just as well) and are copied to the output folder as a first step after all the source data has been sent from the source. MSBuild pretty happily raises a DLL from its output folder, and this way we also avoid having a lot of binaries in the source control.