Ever wondered how you would end up writing unit tests for VSTO applications? Varsh (my colleague at MS, does a great job of explanning the "how-to" behind writing those unit tests).

Check it out at: http://blogs.msdn.com/b/varsha/archive/2010/08/17/writing-automated-test-cases-for-vsto-application.aspx?CommentPosted=true#commentmessage

Here is the slide deck and the demos that Sanjay and I did for TechEd 2010

TechEdDemos.zip (623.32 kb)

Win7 Application Development Reloaded.zip (508.78 kb)

Finally the article is up on MSDN

http://msdn.microsoft.com/en-us/library/ff191178(office.14).aspx#additionalresources

Cheers!

About time I got back to blogging. I know I have been away for a while. Any way, here' s small link to a big article.

I have been working on Office Customization Projects lately and over a period of year n half, I have gathered a whole bunch of information on how to really juice out the best out of office while doing office programming. It's exciting but can really get messy at times (lol). A few of my colleagues and I, authored an article that gives some insights into some of the aspects of using OpenXML. The article particularly talks about increasing processing performance while using large amount of data with MS Word automation and how we can leverage OpenXML to achieve this.

Eric White, from the Microsoft Office Open XML group was kind enough to host this article on his blog, since it's going to take a while for the article to show up on MSDN.

So here's the link to the article "Increasing Performance of Word Automation for large amount of data using Open Xml SDK"

 Enjoy and let me know what you think.

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!