Continuing with my work on converting a legacy application from Leadtools Medical v14.5 to Leadtools Medical Suite v 19 I came across the following annoyance which I felt compelled to share. One of the issues with moving a fairly complex and large application from one series of libraries to another just how you go about breaking things. Any fool can rush in deleting reams and reams of code and replacing the old libraries with the new libraries and then writing thousands of lines of new code only to find that the intent of the application is now not right and it is no longer functioning as was intended. Yes, user testing will pick this up but user testing is to make sure a product is ready for release, and NOT an extension of development.Unit testing will pick up some issues but in general the bugs will be many fold and extremely subtle, especially in already complex software. The key to migrating a functioning LOB application from one library set to another is thus breaking things slowly and in a controlled manner (much as I love the ‘Move Fast and Break things’ approach of Facebook which is fine and dandy if you are the client and accept the risks, generally they dont!).
In addition to making heavy use of unit testing to verify that key libraries are behaving as they should across libraries I decided to use Conditional compilation to allow me to flick between libraries for the purposes of comparing, contrasting and sanity checking. I am however not a fan of this sort of thing:-
So I decided that rather than this I would utilise the much tidier looking Conditional attribute as shown below which appears much less verbose and gives the added benefit of allowing intellisense on code currently hidden to the compiler (although I would prefer it there was a visual indication that the code was to be ignored during the compilation process):-
Sounds like a great plan, however, I had not realised that the Conditional attribute came with restrictions, restrictions that make it actually pretty much useless. Firstly I have one central class for dealing with the majority of Dicom work called DicomUtils. I created a second version of this class using the newer libraries and decorated the original class with the conditional attribute. All good? Well, No, The first restriction I came across is that classes cannot be hidden using this attribute. Onward and upward…. I then tried to apply the attribute to my formatTag function as above which was when i ran into the deal breaker, It can only be applied to void methods! Any function that returns a value cannot be decorated in this way. I understand (kind of!) that the restriction is placed as you may assign a variable with the results of a function, well…. yes… but why not let the compiler spit out warnings instead of just creating a class that offers only a portion of the power it should provide, I mean really what is the difference (other than fugly code) of the $if directive applied to a function and the conditional attribute applied to the same function. None I think, other than the fact that the directive may be more entrenched into the compiler.
Looks like it’s time to break out the ugly code…..