InstallLicense Issues

Hi, 

We have an issue where InstallLicense does not appear to work correctly.

SETUP

We have a standard solution with a main executable, a common framework, and multiple plug-ins that all use the Mindscape controls.

All the projects (inc. the executable) has the required references to the Mindscape DLLs, we have generated the runtime licenses as instructed and 'install' them in the application's Main.cs as per below:

public static void Main()
{
   // install Mindscape licenses
   Mindscape.WpfElements.Elements.InstallLicense("###");
   Mindscape.WpfPropertyGrid.PropertyGrid.InstallLicense("###");
   Mindscape.WpfDiagramming.Foundation.DiagramSurface.InstallLicense("###");

   App().run();
}

REPO

When we try to access/run one of the plug-ins it fails to find an installed license. We have also tried embedding the licenses in the executable project to no avail.

The issue was not noticed before today as during development we always had Mindscape installed locally our machines.

This is also the first build that we have switched over to installing the licenses at runtime, previously we have had the *.lic files sitting next to the the DLLs (very bad).

CALLSTACK

System.ComponentModel.LicenseException: No License Installed
   at Infralution.Licensing.EncryptedLicenseProvider.GetLicense(LicenseContext context, Type type, Object instance, Boolean allowExceptions)
   at Infralution.Licensing.PublicEncryptedLicenseProvider.GetLicense(LicenseContext context, Type type, Object instance, Boolean allowExceptions)
   at System.ComponentModel.LicenseManager.ValidateInternalRecursive(LicenseContext context, Type type, Object instance, Boolean allowExceptions, License& license, String& licenseKey)
   at System.ComponentModel.LicenseManager.ValidateInternal(Type type, Object instance, Boolean allowExceptions, License& license)
   at System.ComponentModel.LicenseManager.Validate(Type type, Object instance)
   at Mindscape.WpfPropertyGrid.LicenceHelper.ValidateLicence(Object sender, RoutedEventArgs e)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target, RoutedEventArgs routedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
   at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
   at System.Windows.UIElement.RaiseEvent(RoutedEventArgs e)
   at System.Windows.BroadcastEventHelper.BroadcastEvent(DependencyObject root, RoutedEvent routedEvent)
   at System.Windows.BroadcastEventHelper.BroadcastLoadedEvent(Object root)
   at MS.Internal.LoadedOrUnloadedOperation.DoWork()
   at System.Windows.Media.MediaContext.FireLoadedPendingCallbacks()
   at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
   at System.Windows.Media.MediaContext.RenderMessageHandlerCore(Object resizedCompositionTarget)
   at System.Windows.Media.MediaContext.RenderMessageHandler(Object resizedCompositionTarget)

For our repro purposes, do you also have any ILMerge stuff going on here?  That's usually the reason for needing to do an InstallLicense rather than just letting VS embed the licence resource via licenses.licx.  Is it feasible for you to create a small solution (just a main EXE and a single plug-in DLL) that demonstrates your entire build / run workflow, specifically including custom build steps such as ILMerge?

Thanks for the replay Ivan.

We do not use ILMerge as a post-build action. At the end of a successful build we collect (using a simple batch file and xcopy) all the DLLs and PDB files to final directory. In that final directory we have three locations on the probe/search path: current executable directory, a DLLs and a Plugins sub-folder.

We prefer the InstallLicense() method over embedding the *.lic files as consitent with our other middleware licensing and prefer to manage it all in location.

If you really need a small solution to repo the issue that I can create one, however as far as I can see there is nothing special about the setup.

A current workaround is to place the *.lic files next to the Mindscape DLLs, however that is not ideal.

NB: We are using VS2005.

BTW: just noticed, I attempted the embedding license path out of frustration yesterday however I only had *.lic (not *.licx) files. What is the difference and how do I generate the *.licx files?

Licenses.licx is a small text file that lists licensed components.  If you have a licenses.licx in your Properties folder, with the Build Action set to Embedded Resource, then VS will read the .lic files for the listed components -- which contain the actual licensing keys -- and created embedded runtime licences, so you will not need to call InstallLicense().

You can copy licenses.licx from any of the sample projects included with the controls.  However, because you are using several separate products, you will need to merge the licenses.licx from each product.  To do this, take a copy of licenses.licx from one product's sample project.  Let's say you take a copy of licenses.licx from a WPF Elements sample.  Then open up the licenses.licx from a WPF Property Grid sample, and copy everything from there into your copied licenses.licx; then do the same for the diagramming product.  (I've attached a copy of the resulting licenses.licx; you can just use that if you like, but I've left the explanation in for future reference.)

Once you have done this, add the combined licenses.licx to your project's Properties folder and set the build action to Embedded Resource.  Remove the calls to InstallLicense (as these will prevent the licence manager from finding the embedded licence).  You should now find that it all works and that you do not need to deploy the .lic files (which are not embeddable and not redistributable).

Note that as per the licensing FAQ you will need to compile licenses.licx into both the DLLs *and* the main EXE -- basically any project that references the controls, directly or indirectly.

We strongly recommend this method because it is the standard way of handling runtime licences on .NET.  However, if you really prefer to install the licences through code then let me know and I will try to reproduce this issue.  Sorry about the ILMerge confusion: I must have had you mixed up with another customer for whom we originally added this feature (which was only ever intended for the ILMerge scenario where the standard licensing mechanism doesn't work).

If you're happy to use the standard mechanism, but you're still getting licensing errors after making these changes (and if the licensing FAQ doesn't help), let me know.

Honestly we would prefer the InstallLicense() method as we have ~18 projects/DLLs (including the executable) that require Mindscape licensing. The InstallLicense() method is far more simple because it is only in one location for the entire solution.

Fair enough, that makes sense!

I have started to investigate this but I can't get this problem to reproduce in my simple naive test.  I've attached a sample solution which works for me.  Could you run this up and let me know if it works for you (when you substitute in the appropriate runtime licence in WonderApp.cs)?  I can also supply the compiled output so you can test whether that works if it would be useful.

If it does work for you, can you identify any differences between the structure of the test application and the structure of your real application that might help us to reproduce the error?

Thanks Ivan. I will try to reproduce the issues within your test application. Will get back to you as soon as possible.

Hi Ivan,

I was unable to reproduce the issue in either provided test application or in the cutback implementation of application structure :/.

Attached is the project that I just created. At first I thought it could be that we load the plug-ins at runtime from the Bin\Plugins sub-folder and do not directly reference them in project (not the case, as you will see in the attached solution).

This is an indeed frustrating issue, I almost want to revert to using *.licx files so I can continue with more pressing tasks.

Any ideas?

Hi Ivan, I have found the cause of the issue, it actually has nothing to do with the structure of the application. I have a few questions and a possible solution written at work that I will post in the morning.

I'm continuing to track this issue further into the licensing code and it appears that the valid license is being disposed of when the FrameworkElement is unloaded (CleanupLicense() in 'LicenseHelper').

Normally I suspect this would not be an issue however with our window docking solution, SandDock,  I believe our controls are being unloaded and the license is being disposed. As a temporary hack to prove the situation I commented Unloaded event and all the plug-ins now load correctly.

Possible fix: In 'LicenseHelper' move the license generation that uses the installed key from Attach() to ValidateLicense(). This way if the license has been cleaned up and is null it will be regenerated.

I can send you the delta if you wish. I also have a two other changes to PropertyGrid that I would like to integrate back into your code base.

Dennis, thanks for the great info.  Your proposed fix sounds like the best way to handle this and if you have a patch then I'd be glad to plug it in.  Just mail it to ivan @ the obvious domain name and I'll get it sorted for you.  If you don't have a patch then no worries, I can make the changes myself.

Regarding the other changes you would like us to integrate, that shouldn't be a problem, again just include them in the email and let me know what they're for, and we should be able to fold them in unless there's any compatibility or API design concerns (in which case we'll let you know our alternative proposed approach).  Thanks again!

I'm glad that we finally tracked the issue, it was very frustrating.I will send you an e-mail shortly with the suggested changes to the LicenseHelper.

My other changes should not propose any issue. They were simple features that we needed:
- Added a MinColumnWidth attached property TreeListView that is used when calculating the fill column.
- Added a command to the ViewCommandsToolbar that clears the search text box (and the active search).

Thanks for you help.