How licenses.licx file is used

Question

I've got licenses.licx file that is included to one of my projects properties. I am not sure how that is used by its dlls. Is it used by msbuild? Do you have any idea how it is used when the solution is building?

Harvest

possible duplicate of How does the Licenses.licx based .Net component licensing model work? – Charismatic

@ROMNANARMY: I went through that thread. It doesn't provide me what I am looking for. I just want to know how licenses.licx works in general. – Harvest

Answer 1

Licenses.licx file woes

File this under ASP.NET, Department of WTF.

Frustration When you are developing a web application with our controls, a mysterious file called licenses.licx appears. No, it's not an order to use a weirdly-named lollipop, but is a transitional file generated (and modified) by Visual Studio that participates in license checking. In design mode, Visual Studio uses this file to make a note of every licensed control you use in your design. When you then build your application, Visual Studio read this licenses.licx file and for every control mentioned there, will load the relevant assembly and run the license code in that assembly to see if the assembly is properly licensed (that is, that the product to which it belongs has been properly installed on that machine). If everything checks out, Visual Studio embeds the license key into the executable. If it doesn't, you'll get weird error messages about the control not being licensed (my favorite is "Could not transform licenses file 'licenses.licx' into a binary resource." to which I usually invoke the colorful language of my ancestors).

Licenses.licx is actually a file in your solution (if you cannot see it there, click Show All Files). Visual Studio uses a program called lc.exe to compile the licenses into embedded resources in your application, and when things go wrong with the license compiling I've seen error messages that reference this executable as well.

Here's an example of a line in a licenses.licx file.

DevExpress.XtraCharts.Web.WebChartControl, DevExpress.XtraCharts.v8.2.Web, Version=8.2.4.0, Culture=neutral, PublicKeyToken=9b171c9fd64da1d1

The first value in this comma delimited list is the class, the second is the assembly where it's found, and the other values are the rest of the assembly's strong name. I'm sure you can see problems already, especially when you upgrade a solution to the latest versions of the third-party controls you use. If you want, you can edit this file and remove the strong name parts with no problem.

But that's not the biggest issue with licenses.licx. The thing is Visual Studio has a propensity of touching this file if you open the solution (that's "touching" as in changing the file date to the current date/time). This plays havoc with licensing, especially if you happen open the solution on a non-licensed machine and you are using source control. Suddenly your build machine will throw off these "cannot transform" messages and you're left wondering what went wrong. Another prevalent issue is when you have a team of developers working on a solution: they're all unconsciously "modifying" this file.

So, the answer seems to be not to put the licenses.licx file under source control. (KB article)

But this solution to the problem throws another red flag: if one of the developers in a team adds a new control that needs licensing to the form, a line gets added to his local licenses.licx file and it may not get reflected in source control. Bam, your build machine fails the build and Joe, who added the control, has to buy doughnuts for the team until someone else breaks the build.

I'm afraid I have no good solution to this latter issue, because unfortunately the "not putting licenses.licx in source control" seems to be the way everyone is solving the licensing problem. Another solution is to delete the licenses.licx file altogether and then get Visual Studio to regenerate it by opening the solution (although this is a bit difficult on a build machine).

Anyway, hope that all helps in some way. And hitting your laptop with a phone isn't really going to help.

Harvest

The last sentence "And hitting your laptop with a phone isn't really going to help." ..... wonderful – Cluny

Answer 2

Since you indicate that StellarEleven's reply doesn't help, I guess you're looking for something even simpler. This is probably not 100% correct, but it is my understanding of how this works:

The licx file is simply a list of the "licensed" components used by your application.

Each line in the file is of the following format:

[Component Name], [Assembly Name]

For example one of my projects uses the licensed IP Works NetDial component so my .licx file contains the following line:

nsoftware.IPWorks.Netdial, nsoftware.IPWorks

In the context of the project (.csproj) file, the .licx file is referenced as an EmbeddedResource. During the build process, LC.exe verifies that the machine performing the build has the appropriate license(s) for the component in question, and generates a binary .licenses file which eventually gets embedded as a resource ([AssemblyName].exe.licenses) in the final executable.

Does this help?

Veneering

Do you have any idea how the LC.exe verifies that the machine has the appropriate license? I've got publicKeyToken in the license file. Is it what LC.exe uses to verify? Thank you! – Harvest

I don't think so. I believe the publicKeyToken you're talking about is used to ensure that the referenced assembly has not been tampered with. The mechanism that LC uses is the one described in the other answer to this question - specifically the LicenseProvider attribute for the component (if any) is located, then queried (a call is made to GetLicense) via reflection. If I understand correctly (and I may not), the License object returned from that call is then serialized into the .licenses file. – Veneering

Unfortunately, because the LicenseProvider is accessed through reflection, each licensed component may (and quite possibly does) use its own mechanism to determine the license status on the build machine. – Veneering

Answer 3

We use a custom check-in policy (TFS) that explicitly nulls the contents of this while if present in the check-in list.

Lippe

Not sure why this is down voted so heavily, perhaps because it would be better as a comment on this answer (see below), as it is a feasible action given this answer: https://mcmap.net/q/319613/-how-licenses-licx-file-is-used – Definiendum