Maintenance release. Some customers reported receiving Invalid Program exceptions with then encrypted version of the licensing runtime. The fix was discovered some time ago, but applied only to the 4.x release. The fix has been back ported and incorporated into the final 3.x release.

See the complete change log.

To download the update select Help | Check for Updates in the DeployLX Manager, or visit the My Account section of the website to download authorized installers.

Subscribe to the update feed to be notified when we release an update.

This is the final release of the 3.x line and includes a few minor usability enhancements and back-ports of fixes made to the new 4.x beta.

• Support for Windows 7.
• Fixed module load exception in Windows Server 2008 x64 with Kill Debuggers enabled.
• Improved the Test License feature in DeployLX Manager.
• DeveloperMode will reset any secure storage tamper detection and will report tampering in the error report.
• See the complete change log and new xbugz.com site for more details.

To download the update select Help | Check for Updates in the DeployLX Manager, or visit the My Account section of the website to download authorized installers.

Subscribe to the update feed to be notified when we release an update.

• Fixed module load exception on 64-bit operating systems with kill-debuggers option enabled.
• Added option to copy details to clipboard from the standard DeployLX Licesning extension panel.
• Calling SecureLicenseManager.ResetCacheXXXX methods will now clear license application state. This state is not used to enforce limits but to enhance user interface such as only showing the Trial form once per session.
• Added Test License button to DeployLX manager to make it easier to test licenses during development.
• When the license changes on the client are persisted they normally always try to save to the original location. If access is denied changes are persisted to a shadow copy of the license. Now, when the client persistence (LicenseFile.SaveTo) is NotSet, DeployLX will detect if the license is embedded and would normally be saved to the Program Files folder and will automatically use the shared folder instead.
• Added new option to Trial and Activation limits to control when the form is shown. The FirstTimeAndExpires value will show the form the first time the license is validated, then only again after the trial or grace period has expired.
• Fixed FieldAccessException when referencing public fields of types that also include private fields from another assembly.
• Added ability to obtain the deactivation codes when calling SecureLicenseManager.Deactivate.
• Changed the CodeVeil MSBuild targets to automatically be included in the build process at the end of the CoreBuild target.
• Resolved logic that allowed any returned value from a License Server to be ignored when Can Skip Server was selected in the Registration Limit.
• Fixed InvalidFormatException with non-english translations.
• When closing a project in the DeployLX Manager, if changes had occured since the last save the user was prompted. Selecting Cancel from the dialog box would result in the project being closed, unsaved, and any changes lost. Resolved the conflict to return to the project without closing it.
• Fixed inheriting from nested class causes stack overflow exception.
• See the complete change log for more details.

This update is free to users with a current Assurance Contract or those that purchased within the past 6 months.

To download the update select Help | Check for Updates in the DeployLX Manager, or visit the My Account section of the website to download authorized installers.

UPDATE: We had a small bug in the build script that was marking the builds and change log with an older build number. This has been fixed and the version number is correct in all locations.

There may come a time when you want or need to issue a custom license to a specific user. This can be for an extension of a limit, a change in licensing requirements, or simply to test different scenarios on a customers machine.

Simply build the license file to the specification you want to allow, and send the user the license file signed by the same keys that are in the existing project. When I say the license file, I mean the .LIC file that you created in the DeployLX Manager and saved. Have the user copy this file to the running directory that the existing deployed license file is running from. As long as the license file is saved in the working directory (or along the standard search paths) DeployLX will pick it up. To find out the search path DeployLX takes, you can take a look here.

Another trick you can use is to pre-register the license, or specify a specific serial number for a user. You can do this and not even give them the option to enter a serial number. Generate a serial number and add it to the Serial Number box in the DeployLX Manager. Once you have done this, save the license file. Now the serial number is already added to the license file and does not have to be entered. This can be done through code to prevent screens from being displayed

LicenseValuesDictionary licenseData = info.RegistrationInfo;  licenseData[ "userName" ] = _userName.Text; licenseData[ "organization" ] = _organization.Text; licenseData[ "serialNumber" ] = _serialNumber.Text;

or when creating a license file through code.

I feel it is best to allow for extensions and not use it, then to need it and not have it. Here's my thought.

More...

Well, we here at XHEO have been working on a side project, and we’re about ready to roll it out. We’ll be going beta soon so everyone will have a chance to take a look at it and give us some feedback. Want to know what’s new? Read on.

More...

Licensing is the first and last thing your customers will see. So deciding how your license scheme is going to flow is important. Do you let your customer install the product completely? Or do you check the license prior to installation begins? Both are valid scenarios, and have their own place in business.

More...

When any DeployLX screen is displayed a record is kept of error messages and logged data. So when the behavior of the license seems abnormal, or is unexpected, there is data that might not be shown. How do I get that data?

More...

When testing different license scenarios we have provided a Developer Mode to make it easier to reset the license state to it’s “clean” form so you don’t have to set up a virtual machine just to test a few ideas. During development it’s easy to just turn developer mode on by default for debug builds with the following code:

   1: LicenseValidationRequestInfo info = new LicenseValidationRequestInfo();

   2:  

   3: #if DEBUG

   4: info.DeveloperMode = true;

   5: #endif

   6:  

   7: SecureLicense license = SecureLicenseManager.Validate( this, null, info );