An easy approach to building apps that use third-party controls from companies such as Telerik, DevExpress, Infragistics, and others, without having to install these controls in every single build node, for the sake of compiling the licenses.licx file.
Easy continuous integration of apps using third-party controls that rely on licenses.licx files.
EmptyLicensesLicx alternatives and similar packages
Based on the "Build Automation" category.
Alternatively, view EmptyLicensesLicx alternatives based on common mentions on social networks and blogs.
9.4 9.6 L1 EmptyLicensesLicx VS MSBuildThe Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
8.8 8.8 L3 EmptyLicensesLicx VS Cake:cake: Cake (C# Make) is a cross platform build automation system.
6.0 8.4 EmptyLicensesLicx VS FlubuCoreA cross platform build and deployment automation system for building projects and executing deployment scripts using C# code.
3.9 0.6 L5 EmptyLicensesLicx VS AlbacoreAlbacore is a professional quality suite of Rake tasks for building .NET or Mono based systems.
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of EmptyLicensesLicx or a related project?
An easy approach to building apps that use third-party controls from companies such as Telerik, DevExpress, Infragistics, and others, without having to install these controls in every single build node, for the sake of compiling the
Give a Star! :star:
If you like or are using this project please give it a star. Thanks!
When you are developing .NET applications that use third-party controls such as the ones that you can buy from Telerik or DevExpress for example, a mysterious file called
licenses.licx appears inside the
Properties folder of your C# project (Or
My Project folder if you're using VB .NET).
This means that the third-party control uses the licensing model provided by the .NET Framework for licensing components and controls.
This file 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 reads this
licenses.licx file and for every control mentioned there, loads the relevant assembly and runs 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.").
licenses.licx is a file automatically added to your project (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 process, you might see error messages referencing this executable.
Here's an example of a line in a
DevExpress.XtraCharts.ChartControl, DevExpress.XtraCharts.v15.2.UI, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b88d1754d700e49a DevExpress.XtraMap.MapControl, DevExpress.XtraMap.v15.2, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b88d1754d700e49a Infragistics.Win.Misc.UltraButton, Infragistics2.Win.Misc.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb Infragistics.Win.Misc.UltraGroupBox, Infragistics2.Win.Misc.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb
Each line contains a reference to a type that is contained in an assembly, in a comma delimited list format. The first value is the full name of the class, the second is the assembly that contains the class, and the other values are part of the assembly's identity.
There are many issues caused by having to compile this file. For example, when you upgrade a solution to the latest version of the third-party controls you use, you'll get compile errors until the file is updated manually by you, or until you manage to get Visual Studio to regenerate it.
But that's not the biggest issue with
licenses.licx. The thing is that 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 to open the solution on a machine that doesn't have the third-party controls installed. 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: Visual Studio will make changes to this file as they interact with the third-party controls during development.
The solution for the
licenses.licx problem is to make sure you always have an empty
licenses.licx file in your project. That does not mean to delete the file... That means ignoring the changes that Visual Studio makes to this file, and removing all of its contents, effectively making this file completely empty - but still keep the file there during build and ignore it in your source control system.
This means every developer in a team needs to know that and remember that before checking-in code to source control.
And that is the main reason I've created EmptyLicensesLicx.
After installing it via NuGet:
PM> Install-Package EmptyLicensesLicx
> dotnet add package EmptyLicensesLicx
a reference to the EmptyLicensesLicx.targets file will be added to your project, which will hook into the build pipeline and to make sure that the
licenses.licx file is always empty before the compiler tries to compile it.
This means you no longer will see the "cannot transform" errors in Visual Studio, or when using MSBuild in your continuous integration server. In fact, if this is the only reason you have been installing these third-party controls in your build servers, you no longer have to.
Does that mean no license is embedded in my app?
Yes, that's correct. In most cases this is not problem at all, and it all depends on how the licensing of the components you're using work. Most .NET control vendors nowadays such as DevExpress, Telerik, Infragistics, ComponentOne, etc. do not require a license for distributing your application (i.e. There's no license check when your application runs in
Release mode), so you don't need to embed any licenses with your apps during build for it to run.
Most vendors require you to have a valid license for development purposes only, and the license check is enforced during development time, usually when you're designing your UI (e.g. using the Visual Studio designer), and/or when you're running your app in
This is why having an empty
licenses.licx works for the purposes of building your app, and it also saves you from having to install the vendor control suite on your build server.
However, if you are using a third-party control that requires a runtime license (i.e. the license is required to run your app on any machine) then the empty
licenses.licx doesn't make sense for you, and you do need to embed the licenses with your app during the build.
Click on the Releases tab on GitHub.
Copyright © 2016-2021 C. Augusto Proiete & Contributors - Provided under the [MIT License](LICENSE).
*Note that all licence references and agreements mentioned in the EmptyLicensesLicx README section above are relevant to that project's source code only.