Licenses.licx file woes

06 March 2009

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=, 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.

9 comment(s)
Aaron Smith

What we do, is delete the file from the solution and then save everything and check everything into source control. Then we open a form and let it create the license.licx file. We save the project file and then check everything in, EXCEPT the licenses.licx. Then we undo the add of the licenses.licx to source control. Then each developer just has to copy in a blank licenses.licx file to the project and it happily updates it without ever wanting to check out the file or check it back in. On our build machine I have a script that just copies in a known good licenses.licx file so that the build succeeds.

6 March, 2009
Charles Mussely

What bugs me is that after all that XML hype for defining projects, app.config/web.config, that file is still a flat text file.

6 March, 2009
Christopher Todd

We source control it, but we pay close attention to how we check it out when it is needed (which is every time you open something). We allow everyone to check it out at one time and we merge the changes later. I think the most frustrating part is that the file sometimes changes dramatically even though nothing was changed and the merge becomes a nightmare.

I'm curious as to what happened recently that got you thinking about this. I hope it doesn't delay the beta!! Big Smile

6 March, 2009
Roger Areia

We are using a source control solution that allows concurrent editing (rather than locking) and since there are only very rarely conflicts in the resulting lic file, we don't have problems managing the file.

I ran into another problem the other day.  We generally we freeze the version of DevExpress for each release and update to the next stable release at the start of the new revision.  When we branch the SCM, we include the required devexpress dlls in the source control.  The other day I tried to build a branch that required 8.3.2 and I had 8.3.4 installed on my development machine.  During the build, the license compiler barfed because it was looking at the versions in the GAC (8.3.4) and the lic file required the release version (8.3.2),  Are there any work arounds for building with previous versions of devexpres without actually installing the previous version?

7 March, 2009
Daniel Hulse

We run into this problem as well. We are using Perforce as our SCC, and have set up a rule in Perforce to not accept the check-in if the project file references the .licx file. The developer gets the error upon submitting and can then fix or revert the project file.

7 March, 2009
Chris Lively

We simply hand added all of the relevant assemblies to the license file whether they are used or not.  Then we copy that license file into each new project.  So far, no issues.

10 March, 2009

We don't check it in to source control, and I've created a DxCore plugin that monitors the projects in the solution and removes the file when it gets added (remove, not delete, so the design time components can still access it).  This keeps us from having a missing project reference when we least for those developers who are using CodeRush (we still have some nay-sayers in our midst)

12 May, 2009
Csaba Toth 2

Question: We don't keep it in source control either. How can I prevent Visual Studio from creating the licx file all the time?

5 August, 2013
Bipendra Saw

i have deleted licence.licx file from my solution but still showing licence information on my website

please help me out as soon as possible from this problem it's annoying very badly

25 February, 2019

Please login or register to post comments.