Blogs

This Blog

News

Favorite Posts

Archives

ctodx

Discussions, news and rants from the CTO of DevExpress, Julian M Bucknall

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.

Published Mar 06 2009, 11:41 AM by
Filed under:
Bookmark and Share

Comments

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.

March 6, 2009 4:09 PM

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.

March 6, 2009 5:14 PM

Christopher D. 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

March 6, 2009 11:33 PM

Paul A. CHEVALIER

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?

March 7, 2009 3:15 AM

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.

March 7, 2009 6:53 AM

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.

March 10, 2009 5:51 PM

Casey

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 build....at least for those developers who are using CodeRush (we still have some nay-sayers in our midst)

May 12, 2009 12:23 PM

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?

August 5, 2013 6:01 PM

About Julian Bucknall (DevExpress)

Julian is the Chief Technology Officer at Developer Express. You can reach him directly at julianb@devexpress.com. You can also follow him on Twitter with the ID JMBucknall.
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners