Daniel Fisher (lennybacon.com)

SOA, DATA & THE WEB

.NET Licensing - ode to monolithic applications?

The Microsoft .NET Framework has a built in licensing technology. It can be found in the namespace System.ComponentModel and System.ComponentModel.Design.

Here is a small sample implementation of the minimal required classes:

A lot of component producers use this licensing model – so does Tx Text Control – the component that I wanted to use.

As a user you just create a *.licx-file, include it into the project as “embedded resource” and add the components that should be licensed by their fully qualified type names – one per line:

During the build the LC-Task executes the license compiler (LC.exe). The license compiler is part of the .NET SDK that is part of the Windows SDK. If you have the Windows SDK 8.1 or Visual Studio 2013 installed it can be found at “C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\”.

The result is the “Licensing.dll.licenses” file that is embedded by the C#-Compiler (Csc.exe) in the next step.

During runtime the LicenseProvider-attribute is evaluated and the defined license provider is handed over to the System.ComponentModel.LicenseManager’s Validate method. This call forwards to the internal method ValidateInternalRecursive which then calls the GetLicense method of the LicenseProvider. The first argument of the GetLicenseCall is of type LicenseContext and at runtime filled with the static held instance of the internal class RuntimeLicenseContext. To resolve the license key the method GetSavedLicenseKey is called on the LicenseContext. The implemention offers two options to resolve the key:

  • Resolve from URI:

    new Uri(new Uri(AppDomain.CurrentDomain.SetupInformation.ApplicationBase), AppDomain.CurrentDomain.SetupInformation.LicenseFile)

  • Resolve from Embedded Resource:

The lookup on references/loaded assemblies is only processed, if there is NO entry assembly - for instance within ASP.NET that is the case.

But my intend was to create a build task for MsBuild that converts Microsoft Word’s DOCX files into PDF documents. So I have an entry assembly (MsBuild.exe). The entry assembly knows nothing about TX TextControl – and that is a good thing! I have no control over the entry assembly (MsBuild.exe).

A situation I guess to find in every composite UI/modular desktop application. No wonder the monolith is often the preferred architecture especially on the desktop!

After an intense debugging session through the framework sources (supported by red gate’s Reflector) I wrote a small helper class.

WARNING: I use reflection to access internal types and private fields and modify their values – this means: If Microsoft decides to change their internal implementation it might not work anymore. But as we as can see the code was written for .NET 1.0 and has not been updated in the last 10 years: It’s not very likely that changes will happen.

Now I just need to call LicenseLoader.LoadLicensesFromCallingAssembly() before the Tx Text Control component is instantiated the first time and everything works as expected.

HTH

Comments

Write a comment