On occassion one might have the need to browse .NET's Global Assembly Cache -- to manually update a file during development or to remove an assembly left behind by an installer. Normally you'd use gacutil to add or remove assemblies from the GAC during testing and development. However if the assembly was added by an installer, gacutil refuses to remove it.

In the previous post, I showed how to use the Session.Get<T> syntax against an arbitrary property on the entity. The primary limitation with that method is that it only works for constant values. The following will work with constants, local variables, return values from methods, etc.

While many of my entity classes use surrogate primary keys, they also have natural keys (Product SKU for example). When I want one of those entities it's more natural to use the natural key, naturally. Normally that requires a CreateCriteria call, I'd rather just call Get<T> like I can with the surrogate keys. So I created an extension method that lets me do this:

Ever wished you could test the output of your MailMessages without actually sending the message anywhere? You could use the DeliveryMethod of the SmtpClient with SpecifiedPickupDirectory and try and round trip the email through the file system. This is troublesome as you have to remember to delete all the files in the output directory before calling Send, then scan the folder for the new file. It also prevents you from any sort of multi-threaded testing.

When upgrading from Windows Vista to the new Windows 7 RC some customers have complained of license access errors when running their protected software. DeployLX Licensing contains anti-hacking features to detect when a hacker tries to delete the secure storage.  When detected any license that uses secure storage (such as those containing a Time limit or Activation limit) will fail -- informing the user that they need to run the application as an administrator at least once. However running as an administrator does not resolve the issue because the secure storage is still missing.

During the upgrade process the Windows Setup only copies the first entry in the secure storage database. When the protected application is run for the first time after upgrading the first run markers are found, but the secure storage is missing. DeployLX Licensing detects this and employs the anti-hacking technique described above.

A fix for this process has been added to the nightly builds. For those using the embeddable source, please contact support to obtain corresponding nightly build.

The fix will when installed before or after the OS upgrade will permit the user to run the protected application once the OS has been upgraded.

For some reason, every project in my solution has decided to rebuild every time I try to build the solution -- even if that particular project has no changes and none of the dependent projects have any changes. I thought it might have been cause by my recent change to turn Copy Local off for inter-solution references to help speed up the build process. But even reverting the code didn't seem to fix it. Deleting the .suo and .user files that Visual Studio keeps it's editor state in didn't help either. So I decided to track down the issue.

"We have sent dozens and dozens of questions to XHEO and we typically receive answers the same or next business day. They even added a feature for us! Some of our initial ideas turned out to be more restrictive than we really wanted but XHEO helped us tune our license parameters to fit our needs. I think we have achieved strong protection without ruining our paying customer's experience. We could not have gotten our anti-piracy solution implemented in time without their help, and we did not have to compromise."

Rolf Fischer 
Chief Architect 
DashWare

Highlights

• 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.

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.

From time to time .NET developers will need to use a native Win32 API to get some platform specific work done. One of the first things I ask myself when I start writing out Interop signatures is "Does the .NET framework already support this?". The breadth of classes in the framework can be daunting and it's not always easy to answer that question. Often the conversations and references online revolve around the native API so that isn't always a help. Searching the MSDN docs can also lead to dead ends as the concepts and naming conventions are often modernized in the framework.