I have my colleague Jamie to thank for this particular blog. I have recently come to migrate a legacy project written using Leadtools v14.5 to v19 of the Medical Imaging Suite and so during a conversation with Jamie he showed me a nice way of embedding the Leadtools licence and developer key within the .NET application. I’m sure it’s not going to bring about world peace or halt global warning but it might stop you prematurely looking like the guy above without the aid of a CT scanner. In all seriousness its just a nice tidy way of handling the licensing, So with out further ado:-
1. Right click on your project and select ‘Properties’
2. Select the ‘Resources’ tab. You may need to create a resources if you don’t already have one using the very self explanatory link on the properties tab.
3. Open the drop down toolbar menu as shown below and select ‘Files’
4. Add the two files you wish to add, the Developers Key (DEV_KEY) and the License Key (LIC_KEY) using the ‘Add Resource’ toolbar item from the following screen
5. OK. We’re now ready to add some code. Here is the function that I created to License the Leadtools libraries ready for use:-
The following lines of code are the ones we are really interested in:-
byte[] licenseBuffer = Resources.LIC_KEY; string developerkey = Encoding.Default.GetString(Resources.DEV_KEY); RasterSupport.SetLicense(licenseBuffer, developerkey);
The first line of course reads the license key into a byte array, the second reads the developer key into a string and the third key sets the License using these two values. Nice and simple. The rest of my function purely deals with knowing if this function has been called before as this code may be referenced in many different places and we only need to set the license once.
As an aside if you are wondering about the verbosity of my variable and method naming it s because I am giving this ‘No Comments’ thing a go. I am starting to come round after many years to agree that commenting code may actually be a BAD thing. For a fuller description of this follow this link here which is the sadly not the article that prompted me to try it out. The main crux of my argument is that Code is code and is maintained, the intent rarely changes and when it does the programmer always does so to the best of their ability at that time. Comments however are written once, mostly poorly, and are NEVER maintained and thus as the program lives and breathes and evolves the comments stay as they were when written; a testament to good intentions, a museum piece bearing no resemblance to reality.
So… we’ll see how it works out, I feel a blog coming on!