March 7, 2021
Hot Topics:

Applications Licensing using the .NET Framework

  • By Kenn Scribner
  • Send Email »
  • More Articles »


The premise behind LicFileLicenseProvider is simple—it checks for the existence of a license file, and if the file exists, it checks the file contents for validity. The file may physically reside on the disk with the application, or it may be encoded as an application resource if you write some additional code to dig it out. If the file exists and has valid contents, the license provider issues a license to the license manager and ultimately to the control. If not, the license provider will throw a LicenseException and your control should then choke and die.

LicFileLicenseProvider overrides GetLicense(), as it must, but it also provides two additional virtual methods, IsKeyValid() and GetKey(). If you use LicFileLicenseProvider as it's implemented in the Framework, GetKey() will look for a file in the assembly's execution directory named {full name}.lic, where {full name} is the full type name of the licensed control class, typically {assembly name}.{class name}. If the assembly MyControlAssembly exposed the licensed control I've been using in my example thus far, the license file would be in the file named:


With the contents of the file in hand, IsKeyValid() compares the file contents with the string "{licensed class} is a licensed component." (period included). For my example, the file MyControlAssembly.MyLicensedControl.lic would contain the string "MyControlAssembly.MyLicensedControl is a licensed component." If the license file is missing, or if the contents are incorrect in any way, the validation fails and the control should fail to instantiate. I've included with downloadable samples solution an example that has a licensed version of the MSDN sample color-picker ComboBox control.

Since IsKeyValid() and GetKey() are virtual, you can easily derive a new class that looks elsewhere for the license file or validates against a different string (perhaps one that's encrypted or one that simply uses a different phrase). A "good" implementation, however, would still deal basically with license files since the base class exposes such functionality. If you would rather implement a totally different licensing scheme, it's a better design choice to derive a license provider directly from LicenseProvider. Since I believe we can be a bit cleverer, I'm not going to provide an example of a derived license file provider. Instead, I'll describe some alternative licensing schemes...

Compiling License Files

Before I leave license files entirely, I should mention lc.exe. lc.exe, or the license compiler, is a tool that ships with the .NET Framework that will take license file information and encode that as an assembly resource. It's an odd addition to the tools provided by the Framework since the default implementation of LicFileLicenseProvider doesn't look for a resource-based license file, but it does have some interesting flexibility. For one thing, it's an easy way to generate the resource information. But more interesting is its ability to encode multiple license files into a single resource, allowing you to license several controls with differing license file strings at once. A significant limitation in my view is the fact that you must use the assembly linker (al.exe) to assemble your compiled modules and resources. For the command-line lovers, that's no problem. But for those of us that develop using Visual Studio .NET, it's a limitation since Visual Studio .NET doesn't compile or generate multi-module assemblies (although you could embed the resource output into your project file with a build action of "embedded resource").

Speaking of Visual Studio .NET, if you want to create a licensed control, you'll find no automated support in either version of Visual Studio (2002 or 2003). So how do you create licensed controls? The answer is you simply create the file manually and ship it with the compiled assembly. Personally, I add the file to my Visual Studio project with a build action of "none," but there is no requirement to do so. It merely makes source code control somewhat easier as the file can be rolled into my source repository along with the other project/solution files. I still have to manually copy the file to the assembly execution directory.

Page 2 of 4

This article was originally published on September 8, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date