.NET

Bring Out ‘Yer’ Dead

/ The Proud Salopian

legodeadcartFor any Python fans out there you’ll be well aware of the ‘Bring out yer Dead’ scene from the Holy Grail film and this particular blog draws heavily on that sketch for its inspiration. For anyone not familiar with the genius that is Monty Python the scene shows London in around 1665, the populace gripped in the full throes of bubonic plague. Eric Idle is pushing a death cart through the streets yelling ‘Bring out yer dead’. A few residents dump their less fortunate relatives onto the pile of now deceased bodies before John Cleese tries to offload his very much alive grandfather for the full ninepence. Despite the remonstrations from the clearly far from dead old man they eventually come to an agreement, knocking the old man unconscious into the bargain. Nobody expects corpses to have so much to say.

Now, I hear you all say, where on earth are you going with this Mr Salopian? What flight of fantasy are you going to take to equate this medieval scene to 21st century software? How tenuous will this link be?! As it turns out, not very tenuous at all. I am currently in the process of revisiting a software solution that a colleague of mine developed in 2006, not that long ago really but in terms of software (certainly in the eyes of Apple) we can almost regard it as vintage. The development  ecosystem at this time was very different, we were looking at .NET 1.1 – 2.0 and a lot of the component vendors had just put a shim over their existing COM libraries in order to get to market in this newly evolving world of .NET.

I remember clearly, just a few years earlier, the conversation that our small team had abandoning our existing development stack in favour of this the .NET fan-dangled thing. The move at that time seemed gargantuan, now it seems a no brainer. At the time it meant redeveloping all of our live software using a proper language. It also meant leaving my boss at that time behind as he could not adapt to the new language and on numerous occasions he got quite frustrated with the lack of control he now had over the coal face of the code. This conversation was no long drawn out thing, in fact we were standing up  next to my desk when the decision was made. Overnight the tools of the company changed, the very next day we consigned VB6 and Delphi to our history and we started from scratch. We took our living applications and rebuilt them (putting the older, but still functional, incarnations on death row as we did so). For a period of time the doomed applications kicked and screamed and generally did the jobs that they were meant to until over time the new shiny replacements went live. What we had done was the software equivalent of battering Grandpa over the head and paying our ninepence; it stood our applications in good stead for the future.

The problem with this approach is that not every contract affords you this luxury or indeed even if it does rarely do we do it. Generally we work on a very ad hoc basis, refactoring when required, more often than not heavily restrained by the decisions of the past. Each refactor gently tightens the noose as the refactor tends to be for new functionality only and not to take best advantage of the tooling available. And this is the problem, not taking advantage of the ‘latest and greatest’ over time is a false economy. It doesn’t push you as a developer and it makes life harder on the software. It is the age old battle between evolution and revolution writ large.

I am currently in the process of refactoring some code created again around 2006, I think it would be safe to say that right now evolution is not an option on the table. I’m just paying my ninepence and turning a blind eye to the death blow being dealt. Looking forward I can see that in managing our long term projects we need to be much more proactive in pushing out the latest tooling and keeping abreast of the changes in the Eco-system. Not change for changes sake, but change because it is inevitable.

Embedding Leadtools License Files

/ The Proud Salopian

dicomI 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’Properties1

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

Properties2

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:-

License

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!

Its all just words!

/ The Proud Salopian

loremWhilst migrating an existing framework version 2 application to version 4.5 of the .NET framework i came up against the following mixture of words for an error message that to be honest made me just blank over at the descriptiveness of it all.

Mixed mode assembly is built against version ‘v2.0.50727′ of the runtime and cannot be loaded in the 4.0 run-time without additional configuration information.

It is both self-explanatory and in turn just a bunch of words that makes you head for the nearest bar to consider why you ever bothered to learn to read at all. Once my eyes came back into focus again I googled this message and found that the solution was actually quite simple. Now it might just be me being lazy but I would have thought that at compile time Visual Studio would have alerted to me to this issue (as I’m sure the run-time must have known) and asked if it should automagically fix this issue. It didn’t so I’m forced to blog so that I don’t forget the next time this never happens!

OK. So as I said, a very simple fix. To the config of my migrated 4.5 application we simply add the following lines (or change them if they are already there in some manner). The critical line here is ‘useLegacyV2RuntimeActivationPolicy‘ which tells the runtime loading process that version 2 runtime activation is supported. This ‘hack’ is because back in the day when 2.0 was fresh and clean and sparkling Microsoft had never really identified that this was ever going to be an issue. So hence years later we need to ‘Jemmy’ in a workaround.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

Note that legacy apps in the future, say version 4 upgrading to version 6 or 7 will not require this as multiple version of the CLR are now supported completely and from the ground up.For a much fuller digression into the background of this article please see this excellent and in-depth article here.

I hope this helps.

Happy to do superficial….

/ The Proud Salopian

smtp_folderSo…. Sometimes the very simplest of things can take gargantuan efforts to work out and you find out that the detail really is just too much detail.  Just such a  situation happened with me this week when working on a site I am developing. I needed to implement the sending of an email once a post had been received from an MVC page to indicate that a booking had been made. The mail would be sent both to the establishment where the booking was made as well as a copy being sent to the person making the booking. I elected to use the inbuilt System.Net.Mail class, how hard can it be right?…… Well A damn sight harder than I thought that’s for sure! This week there will be no code sample as code was in this instance not at fault or has no bearing on what was happening. To cut a very long and very boring story short it did not matter what I did I could not get the mail class to send the mail; upon sending, the operation would timeout or the server would disconnect etc etc. It made no sense so I took a step back. I had been utilising my Yahoo account using the smtp.mail.yahoo.com server and of course as this was secure and requires authentication I used port 465. So I thought maybe the issue is with Yahoo and I changed to my Google account instead using the smtp.googlemail.com SMTP server again with port 465. Still no dice…..Odd. Much headbanging later and I stumbled across this StackOverflow article which led me on to this blog. Now I’m not going to lie and say that it all makes sense to me. It has at least allowed me to at least find a workaround by in this instance using port 587 on my Google SMTP server. If I sat down and thought about it I’m sure I could understand in finite detail what exactly Explicit SSL is and why the .NET mail client only supports this type of SSL, the point is…. I just don’t want to! I feel like I’ve already wasted enough time dealing with this bug (I’m sorry, Its not a feature its a bug whatever they say and one they seem reticent to fix). Normally I’m a man who likes to get the detail, a superficial overview is never normally enough as it leads to design mistakes. However in this instance I now know in enough detail for me that the .NET mail class does not support all SSL SMTP conversations and I’ll continue to bask in my own ignorance.