Over the past several months, I have been involved in estimating for and execution of small, medium and large migration assignments (visual basic 6 to .NET only). The following post is an attempt to share my experiences pertaining to this exercise. Migration to an altogether new technology or platform has never been easy. Moreover, there are are other things that can make this process more complex and tricky, for example:-

• Large code base (~  2 million lines of sheer code)
• Highly layered architecture with a hierarchy of project (vbp) directories
• Loads (~ 200) of COM components
• 3rd party UI components

There are a few prominent players in the market who provide tools for analyzing the code and also offer migration assistance or consulting services. Some of the tools are:

• VB 6 Upgrade Assessment Tool (Microsoft and Artinsoft)
• Artinsoft's VB Upgrade Companion (Artinsoft)
• VB Migration Partners - VBBulkAnalyzer (Code Architects)

Artinsoft and VB Migration Partner expect you to run their analysis tool on your code base, which in turn generates a code stats report per se. The main indicators in this report are a listing of CLS, BAS, CTL, FRM files with the effective lines of code, blank lines, comment lines, etc. The below table gives a quick overview of features (based on my findings) that are available /not available in the above mentioned tools:

Do let me know if I missed out on any thing or if I have mentioned anything incorrectly in the matrix. I would be glad to correct it.

I personally found the VB Upgrade Assessment Tool more useful and was more comfortable using it. Let’s see why.

The fact of the matter is that a seasoned and experience analyst who has ample amount of time may still be able to estimate the effort that would be required based on the information provided by these tools. However, though VB6 is such an old technology, ironically migration related expertise is still kind of rare. More often than not the general approach that companies try to take is to achieve migration + upgrade of the effective product in one-shot. Unfortunately there aren't any successful case studies to prove that this approach actually works and in fact, this approach pretty much doesn't work. Let's look at what I mean by it doesn't work: Let's look at 2 important statements/views below:

1. Customers mindset
   • When a customer wants to move the existing VB6 solution to .NET there may be one or multiple motivations behind doing so. For example:- Adoption of newer technology which is based on new and more open standards, difficult to find resources who are experts in VB6 and willing to work in VB6,  new functional requirements that demand use of newer technology, integration with other business/ software difficult, etc. There are a load of reasons really.
   • The customer has already done a good load of investment on VB6 solution and they want to spend minimal to move to newer technology.
   • The general tendency in this situation is to find the fastest possible way to arrive at the new solution in order to preserve investment and save on costs.
2. The recommended migration approach is to get the VB6 solution to a .NET 1.1 equivalent and then apply the spice of new technology and refactoring.

Here's a simple analogy:

• I stay in a 10 year old 3 storey building which was one of the best construction 10 years back and it has stood strong so far. 10 years later, I am interested in making some fundamental changes to the building like:
• I want more carpet space in the living room and master bedrooms
• I want to build 3 more floor to take advantage of the new FSI provisions
• I want a sloping roof instead of a flat roof.
• I want larger balconies
• Since it will be a 6 storey building, I will have to provision for a elevator in order to make accessibility easy.
• The foundation slab may be strong enough to hold a 3 stories but not 6 stories.

I want to do more such mods which may directly impact the fundamental architecture of the building. Now imagine trying to do these modifications without really demolishing and reconstructing the building from ground up. The final job done will still be comparable to patch work to some extent. You have no idea what potential damage you might cause to the overall quality and durability of the existing structure in this effort (you might notice water leaks a year down the line and would have no clue about what's causing it!). Also it may be almost impossible to provide some key features like elevators because there was simply no space planned out for elevators when the building was first constructed.

Migration of an legacy app to newer technology is comparable. However, most customers try to achieve 1 & 2 (above) in the same step OR mod the old building completely while staying in it :) This is a fairly dangerous approach. Yes you might end up saving some costs (and at time considerable costs) this way but chances are that you will spend much more in the long run to keep patching the issues that may surface eventually.

Fortunately when it comes to software, things are not so very complex. No you don't have to rebuild you solution from scratch every time...Why? Because there are definite and proven steps to upgrade. There are tools that simply / automate a large chunk of the process.

The typical recommended and proven approach is:

1. Get the legacy VB app to .NET 1.1 (relate this to changing the foundation slab to support a 6 storey building)

2. Now re-factor / build new features to take advantage of newer technologies that support or withstand the new foundation slab...er..platform.

Yes this definitely adds to the cost, but in the long run, you have made an investment.

Now that we have a typically migration approach in place (in a nutshell), let's come back to the tools factor.

The tools or services offered by vendors have a few simple proven steps:

1. Assessment     : Run code analysis tools that give a detailed idea of the complexity of the solution.
2. Code Prep       : Not all VB6 language features have an exactly equivalent in .NET (e.g. Variant).
3. Tool Execution : Run the automated process (tool) to convert the now prepared code to .NET "language" equivalent. 
4. Code Fixing     : Do the final touch up fixes, so that the solution is 100% functional in .NET 1.1
5. Testing          : Verification of the entire functionality
6. Refactoring     : It is way easier to plug out .NET 1.1 code / components and plug in .NET 2.0, 3.0, 3.5 or 4.0 stack.
7. Testing          : Verification of the entire functionality

Note: Testing can be more tightly integrated than what's perceived above.

Now, the above 3 vendors (Microsoft, Artinsoft and Code Architects) have their own flavors of of tools / processes to do assessment and conversion. From my perspective the Assessment phase is super critical and the more information one derives in this phases, the better it is to do a successful migration.

Artinsoft and Code Architects generate a report (detailing the types of components and LOC's against each of those). To those who cannot take this input and proceed (which most of us cannot, especially in a huge project), these vendors offer an additional free assessment service where they try and make sense out of these reports and show you a perspective.

I found the VB Upgrade Assessment Tool quite useful, because it not only does this analysis, but provides me with a extremely detailed input in terms of

1. LOC
2. Various components (CLS, FRM, 3rd party controls, etc)
3. Report on potential code conversion issues and whether it is a coding issues or an architectural issue
4. And most importantly an approximation of effort and cost for the end to end migration process - Analysis to Deployment

Beautiful isn't it!? I can now play around with this reports tweak some effort and cost params and see the impact on total effort and cost.

Now comes the most important issue for which this whole post came into being. The Upgrade Assessment Tool fails in cases where the legacy code base doesn't have it's VBP files in one folder or if the legacy code base has more than 1 VBG files.

The tool offers 3 ways of legacy solution selection for analysis:

1. All project files in a directory (NOTE: THIS DOES NOT SCAN SUB DIRECTORIES) - works only and only if all the vbp files are in the same directory root.
2. Point to a single VBG files - works if there is a single vbg for all the vbp's
3. Add individual projects to analyze - works as long as I don't run out of patience in clicking "Add --> Open File Selection Dialog --> Navigate to appropriate project directory --> Select the VBP File". Imagine doing this repeatedly for 300 projects in a hierarchical directory structure :D ... disguised un-employment huh!

Unfortunately I found myself in the situation described in (3) above. 300 odd projects in a hierarchical directory structure.

Now wait a minute, refrain yourself from assuming that I sat the entire week clicking and selecting individual VBP's. I tried combining 2 & 3. I wrote a simple utility that finds all the VBP files in given directory and lists them in a single file using the following format:

VBGROUP 5.0
StartupProject=<fully qualified path>\Something.vbp
Project=<fully qualified path>\Something1.vbp
Project=<fully qualified path>\Something2.vbp

The smarties would have guessed what we are leading to. If not, then you have not been reading carefully. I wrote above that "I tried combining 2 & 3". What's the purpose...The purpose is to be able to manually / automatically generate a single VBG file that points to all the projects in one go!!!

Now start the VB Upgrade Assessment tool, and chose option 2 ("Group File") on the "Select Source code files" screen and proceed to run the assessment! Bingo!!! it works!!! A load of time saved, a detailed report generated within no time and we are good to proceed to subsequent steps!

That's about it for now. I hope this post helps the needy lot out there who are working hard by clicking and adding VB projects manually :) or simply wondering about how to do the assessment or where to begin.

Let me know your comments.

p.s. This is a draft post. I will do some spell checks and grammar checks refine it soon. Till then adios!

Cheers!

I got a lot of positive feedback for my VTD presentation. I guess, the fact that we decided to actually build the presentation around problem scenarios had a greater positive impact. In the next few write-up, I am going to put up my views about each of the topics that I covered, with relevant reference links and code samples. Hopefully that will help in seeing the virtues, learning and adopting the new framework!

Stay tuned!

Hello! The VTD this time was exciting and it was fun to do a session on .NET 4.0. I hope most of you benefitted from my session, if not all. Once again, the objective was to put forth some of the interesting issues and problems that we face today in general. Perhaps because the problem initially was not realized or probably because of the framework limitations earlier. Frameworks are ever evolving and as our demands grow in terms of productivity, hardware and software, there is a necessity to constantly upgrade our framework so that it meets the most current and immediate future needs.

.NET Framework 4.0 has a load of new things that specifically target, productivity of the developer, performance of the app and overall scalability of the app to co-align with new hardware paradigm that are lately coming into being.

I wish I had a little bit more time to do a few more demos. Nevertheless, we spoke / touched-base on the following with some demos as well:

• Code Contracts
• Background GC
• Type Equivalence and Type Embedding
• Dynamic Language Runtime
• Managed Extensibility Framework

As promised here are some of the demos that I did along with the slide deck. I am intentionally omitting some of the demos, since the code is yet not shareable. However, once I am all set to share that code, I will do so.

Note: The code is for demo purpose only and bucketed from various online / internal sources. I am thankful to my friends in the CLR team for giving me their valuable time and sharing some demos with me in order to make this session successful.

NET4Demos.zip (416.26 kb)

AdvancesInNet4.pdf (543.17 kb)

Cheers!

One of the key thought that comes up as we scratch the surface of MEF is...So what's new? I can use reflection and do that. It's important to understand that MEF is not a magic wand that can dynamically discover "altogether new" functionalities and dynamically plug it in an app. I don't think the programming world has reached up to that level yet where a program is as powerful as a human mind (which by far is the strongest processing machine to date).

If a human is exposed to new things then he has obvious and predictable actions/reactions. E.g. -

1. If someone gives me a book, I know it's a book, I look at the preface section, I look at the index and then I know whether to read the entire book or some sections inside it or just not read it. However, if someone hands me a book that is written in a language that I don't understand, the least I would know is that "This looks like a book" but that's about it. Full stop.
2. You place a ball in my hand. My mind, perhaps by experience knows whether it's a cricket ball, a soccer ball, a football, a tennis ball, etc. And based on that I will try to discover additional equipment that I might have to actually use that ball. E.g. I might look for a bat or soccer shoes or a tennis racquet.

MEF is pretty much the same thing. The application has to know what interface the new/dynamic component is going to expose. The component by-n-large can tweak the functionality specific to it's existence. The application has to be aware of what it is going to expect and clearly communicate that to the external world. I can't blind-fold you and then expect you to know and recognize which object I am throwing at you and to also know how to use it. :) lol.

So to say:

1. An MEF compliant application doesn't need to know the inner workings of the component that is dynamically going to be discovered. Note the component is discovered, but the interface is already know to the application.
2. An MEF application can be compared to an abstraction or a standard that promotes effective reusability of components.
3. As long as the MEF application is capable of publicly declaring that "I can understand and execute an Interface X with functionality Foo", all is good.

A simple yet great example that Sanjay Vyas (a.k.a Guruji) gave me was: Let's say my MEF application (let's say App A) understands an interface called IPrinter that has a Print method. Then there are several possibilities:

1. The developer can write his component / plug-in (e.g. which Prints to a printer) against this interface without worrying about how the App A will discover, load it and execute it.
2. The same component can be plugged into another app B which also complies to IPrinter interface with Print method.
3. The developer of neither App A or B or the component itself have to write any pieces of complex reflection code or some config file based code to dynamically discover and used the component.
4. Moreover another developer can implement the same interface and write a component that prints to a PDF file and drop the assembly into the path required by the application and the application can there-after dynamically discover this new component. The fact remains that the app will still be able to only call the Print method of the component. If the new component has a "Sing" method, the application will slap you back! (just kidding...no it will not know what to do with it and it won't even discover it).

In short what we are making available is a framework which will promote in-app, cross-app, cross-vendor reusability. It's a solid vision and it will take time to first establish itself as a standard that developers start adopting and adapting to. It's all about simplifying the not-so standard process of dynamically loading a plug-in. We (Microsoft) take care of the framework, you (end-user developer) just focuses on the functionality or the business problem that the component is trying to solve.

I hope that helps to clarify the thought.

My humble thanks to Sanjay for sharing his insight. It's important to understand the problem that exists, before really jumping to using a technology that is created or brought into existence to solve that problem :) [Well, it's another thing to not know that the problem was actually a problem :)]

Cheers!

DevCon was great fun! It was exciting to be delivering a session on .NET 4.0 and it was even more exciting to be co-delivering it with Sanjay Vyas (a.k.a Guruji). With the new version of .NET it's time the development experience rises to a new and an exciting level. I am uploading the PPT that we used for the session. Readers, feel free to ping me if you have any queries or doubts or share your comments.

Inside_the_guts_of_.NET_4.0.zip (1.04 mb)

Cheers and stay tuned for some more posts on 4.0!

-Sarang