How licenses.licx file is used

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?

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?

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.

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