Goto 100 - Development with Visual Basic : Interop

In VB6 we had the API Viewer, In VB .NET you get the P/Invoke Interop Assistant

Eric Nelson — Fri, 05 Jun 2009 19:27:41 GMT

VB6 programmers will remember a useful little utility called the API Viewer, the helped out when you needed to make a Windows API call.

There is now an equivalent tool for .NET, the P/Invoke Interop Assistant (http://www.codeplex.com/clrinterop ). Not surprisingly it does a little bit more, so as well as enabling you to look up the signature for a particular call, it will also translate snippets of C code.

Notice that it generates required structure definitions to go with your function call!

I also noticed that the P/Invoke Interop Assistant generated code that used the DllImport approach to setting up the API call. I expect this question has been answered loads of times before, but what are the advantages of using DllImport rather than Declare in your VB code? The obvious answer is that DllImport is a .NET way of doing things, but for VB6 programmers of the Declare statement looks much more natural. DllImport does offer much finer control over the way the call is made, but unless you need this fine control you can stick with Declare.

Enhancing your VB6 Application with Interop

Eric Nelson — Fri, 05 Jun 2009 19:21:26 GMT

I’ve been having a look at some of the samples on the Visual Basic Resource Center to see what’s possible when we start using interop between VB6 and .NET. Here are some of my favourites.

This article, “Sharing ADO Recordsets Between Visual Basic 6 and Visual Basic 2005”, looks at approaches to sharing data between VB6 and .NET using the Interop Forms Toolkit. It also serves as a great reminder of the fact that Recordsets can operate in a disconnected mode just like a more modern Dataset. This disconnected mode is the mechanism used to shift the Recordsets from VB6 to .NET and back again.

In the past, creating a multithreaded application in VB6 has been a bit of a challenge. Using Interop it’s now much easier to add this kind of functionality to a VB6 application. The trick here is to make use of the BackgroundWorker component (you could easily apply the same approach using any .NET component from VB6). See “Using Background Threads with Visual Basic 6”.

ClickOnce deployment offers a very clean and simple model for delivering applications to the user’s desktop. At first sight it doesn’t look as if it would be possible to use ClickOnce to deploy a VB6 application because of all registration issues, but this blog post here by Beth shows you how you can make it work.

Adding to the My namespace in VB .NET

Eric Nelson — Fri, 05 Jun 2009 19:16:49 GMT

Just as an aside - after experimenting with the Interop Forms Toolkit earlier this year I wondered how InteropToolbox ended up in the My namespace – it seems like a useful thing to be able to do. I didn’t have to look far, the answer was in the ActiveXControlHelpers.vb file in my Usercontrol project:

   1:  'Adds the InteropToolbox to the My namespace

   2:  Namespace My

   3:      'The HideModuleNameAttribute hides the module name MyInteropToolbox so the syntax becomes My.InteropToolbox.

   4:      <Global.Microsoft.VisualBasic.HideModuleName()> _

   5:      Module MyInteropToolbox

6:

   7:          Private _toolbox As New InteropToolbox

8:

   9:          Public ReadOnly Property InteropToolbox() As InteropToolbox

  10:              Get

  11:                  Return _toolbox

  12:              End Get

  13:          End Property

  14:      End Module

  15:  End Namespace

You might want to have a look at this as well.

That old friend Binary Compatibility – and a FREE eBook on COM Interop

Eric Nelson — Fri, 05 Jun 2009 19:13:17 GMT

A favourite topic for VB6 programmers! Adding a reference to a COM component in Visual Studio adds a reference to a specific version of the VB6 component, so rebuilding the VB6 component without binary compatibility will break the .NET project (you’ll have to re-add the reference to fix it). Switching on binary compatibility in the VB6 project will bring its own set of problems, so a better solution for an automated build would be to run TlbImp on your VB6 dll in your .NET project’s Pre-build event.

I just discovered that TheServerSide.NET has a free book available covering all of the intricacies of .NET to COM interop , so if you want to delve any further take a look here: COM and .NET Interoperability.

Screencasts on the Interop Forms Toolkit 2.0

Eric Nelson — Thu, 05 Feb 2009 17:31:05 GMT

[This is a short post to accompany the UK Secure your Visual Basic 6.0 investment with Microsoft .NET initiative and is sourced from the main VB site]

This how-to video series is focused on the Interop Forms Toolkit and working with Visual Basic .NET and Visual Basic 6 together. The Interop Forms Toolkit allows Visual Basic developers to migrate their Visual Basic 6 applications over to .NET using a phased migration strategy. Instead of having to convert the entire VB6 application at once, the toolkit enables .NET Forms and User Controls to run directly in Visual Basic 6 applications so that you can build the pieces that you need over time.

Presented by Beth Massi

Download the Code: Videos 1–3

You will need: Visual Studio and the Interop Forms Toolkit 2.0 in addition to Visual Basic 6.0

#1 | How Do I: Build Interop Forms?
(11 minutes, 28 seconds)

#2 | How Do I: Build Interop User Controls?
(9 minutes, 3 seconds)

#3 | How Do I: Deploy Hybrid Applications?
(6 minutes, 1 second)

New article on extending VB6.0 applications with the Interop Forms Toolkit 2.0

Eric Nelson — Thu, 05 Feb 2009 16:24:32 GMT

I just wanted to swiftly share some useful links if you choose to extend a Visual Basic 6.0 application including a new article I commissioned in the UK – which turned out rather good.

Firstly links to the toolkit download and some of the best existing articles.

The Interop Forms Toolkit 2.0 which you need to download
Interop Forms Toolkit 2.0 Tutorial on Code Project which includes an example of using a WPF control inside a Windows Form as part of a Visual Basic 6.0 application
Using the Toolkit with Visual Foxpro – yep, you can use the toolkit with VFP9
Using C# with the Interop Forms Toolkit and useful blog post from the team

Which leads me to the new article on using the Interop Forms Toolkit. This is a detailed, code heavy look at using the Interop Forms Toolkit which we are getting some great feedback on.

It covers:

Installation and setup
Interop Forms
Interop UserControls
Sharing data between managed and unmanaged code
Debugging
Deployment
And recommendations on using it

Enjoy.

P.S. I must admit I have never liked the name of this kit as it doesn’t really describe what it does - IMHO. I therefore often describe it as

The Add VB.NET Forms and Controls to your VB6 Application Toolkit

However that does it a disservice. It is broader than that. How about

The Add VB.NET or C# Forms and Controls to your VB6 Application Toolkit

Or even more descriptively

The Add VB.NET or C# Forms and Controls to your VB6 or VFP9 Application Toolkit

The Add .NET Forms and Controls written in any .NET language to any COM based Application but it is much easier to use for VB6 and VB.NET Toolkit

Ok I give in, Interop Forms Toolkit 2.0 it is :-)

Secure your Visual Basic 6.0 investment with Microsoft .NET

Eric Nelson — Wed, 28 Jan 2009 23:36:16 GMT

[This is currently a UK only initiative but you will still find a lot of useful information on the new site and I know our partners are happy to engage worldwide]

Over the last couple of months I have been working with Sarah in my group to pull together something which hopefully will help the many companies in the UK who continue to have a significant investment in Visual Basic 6.0 - and we did it with virtually no budget thanks to some great help and encouragement from Artinsoft, Code Architects and Avanade.

Check out what we created if you are based in the United Kingdom and still have Visual Basic 6.0 applications running your company. Some of the highlights:

A great prize draw to win a free copy of a migration tool from Artinsoft or Code Architects (We have several to give away)
Great offers from our partners. How about a entry level great migration tool for just £199 or 25% off a full blown enterprise class tool
An attempt to summarise the five options you can take along with a 10 minute screencast by myself explaining the five options (and you can tell I had a cold when I recorded it!)
Links to the best resources to find out more
And a a brand new detailed article on the Interop Forms Toolkit which enables .NET forms and controls to be easily mixed with Visual Basic 6.0 forms and controls.

P.S. The web page does have one or two “bugs” – but we will get them fixed on the next refresh.

VB6 Interop and TlbImp vs AddRef

Eric Nelson — Fri, 23 Jan 2009 18:52:28 GMT

I’d always assumed that creating a Runtime Callable Wrapper by adding a reference to the COM component in Visual Studio would generate the same interop code as was generated by using the command line tool TlbImp. That would seem not to be true in at least one case that I’ve discovered, take this VB6 method code for example:

   1:  Public Function ProcessArray(ByRef numbers() As Integer)

   2:      Dim biggest As Integer

   3:      r = 0

   4:      For i = 0 To UBound(numbers)

   5:          If numbers(i) > r Then

   6:              r = numbers(i)

   7:          End If

   8:      Next i

   9:      ProcessArray = r

  10:  End Function

Adding a reference in Visual Studio results in an interop method that looks like this:

Which is not type safe (ByRef System.Array).

Generating the wrapper using TlbImp gave me this signature:

Why do we get this difference? Visual Studio still runs TlbImp, but with the /sysarray switch which forces the use of System.Array. The advantage of the System.Array is that it supports non-zero lower bounds! Check the documentation for its CreateInstance method.

Heads up – The VB6 upgrade guide was written before we released the Interop Forms Toolkit

Eric Nelson — Fri, 23 Jan 2009 18:42:38 GMT

I have been re-reading the ”Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005” guide lately which discusses phased migrations where individual application components are upgraded independently (which I prefer to call “Extending with .NET”). This approach relies on COM Interop to get the old VB6 components talking to the new .NET components – which is great for Business Logic. What the guide doesn’t address are the possibilities opened up by the Interop Forms Toolkit which was released after the guide was written. The Toolkit (amongst other things) allows an application to mix Visual Basic .NET User Interface (UI) with VB6 UI. E.g. An application with 100 VB6 forms could have the 101st form written in Visual Basic .NET – and the users would never know.

It is a real shame we didn’t have the Interpop Forms Toolkit in place when we released the first version of Visual Basic .NET back in 2002. It would have significantly simplified the roadmap and effort involved for companies with VB6 applications.

NB: You can also use C# with the Interop Forms Toolkit to extend VB6 applications.

Feedback appreciated on draft screencast on VB6 and the options to move to .NET

Eric Nelson — Thu, 11 Dec 2008 20:04:52 GMT

I am working with partners to pull together guidelines, resources and special promotions on tools to help UK companies with VB6 make the right choice around moving (or not) to .NET. This will happen early in 2009. There will be a new landing page with the information and on that page will be a link to a 10minute overview screencast. I have created this "draft". Would welcome folks comments.

P.S. It is a draft because it contains some glitches, some odd sound and I sound a little bored at times :-) I'm also not as succinct as I would have liked :-)

Upgrading VB6 applications – a moment to reflect :-)

Eric Nelson — Wed, 19 Nov 2008 00:36:25 GMT

I’ve now spent a bit of time with the book ”Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005”, so what are my thoughts about it? The good news is it remains a comprehensive and valuable resource for anyone planning to move their VB6 applications to .NET. However it is worth remembering that:

It focuses on upgrading rather than interoperating (Covered as Reuse in my earlier post on Rewrite vs Migrate vs Reuse vs Replace). It was written prior to the development of the Interop Forms Toolkit which makes combining VB6 and .NET much easier.
It doesn’t cover any .NET 3.0 or .NET 3.5 topics – nor Visual Studio 2008.

Functional Equivalence vs Application Advancement (and Vertical vs Horizontal)

Eric Nelson — Tue, 11 Nov 2008 12:10:22 GMT

These are a couple of useful terms I’ve picked up from the ”Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005” guide (I really need an acronym to refer to this book!). They refer to two stages of the upgrade process: Functional equivalence means that your .NET application has the same functionality as your VB6 application and the recommendation is that you should get to this stage before you start working on application advancement. Application advancement is when you start adding new or improved functionality, and where you can start to benefit from all the features of the .NET Framework. In many cases I see teams are asked to deliver both in parallel (as I discussed previously) and the end result is at best a lot of late nights and at worst, nothing is ultimately delivered.

Another useful concept discussed in the guide is vertical and horizontal upgrades. A vertical upgrade tackles a vertical slice through all the layers of an application, while a horizontal upgrade deals with a single layer of the application at a time. Which approach makes sense will depend on the architecture of your application. Many teams I have engaged understand the benefits of working with a vertical slice but it is interesting to see that in many cases they choose a poor or incomplete vertical slice. Common mistakes I have seen when teams scope the vertical slice include:

A vertical slice which fails to include reporting and archiving – leaving key implementation details until later
A vertical slice which fails to consider data volumes – the vertical slice is run against virtually empty tables, which masks significant issues with the implementation
A vertical slice which fails to consider concurrency – the vertical slice is never run within the context of simulated load, again masking significant issues
A vertical slice which fails to include interop with existing systems – despite interop being a key requirement of the solution

There are plenty of other examples – but failure to consider the above four can easily lead to significant difficulties later on in a migration project.

Interview with Richard Warnett of Financial Objects on their decision to go with Visual Basic .NET

Eric Nelson — Mon, 03 Nov 2008 17:38:32 GMT

A big thanks to Richard for taking the time to do this. I have known Financial Objects for many years and have been impressed with how they have successfully taken forward their VB6 investment onto .NET using Visual Basic .NET.

I would love to do a few more of these with UK companies who have happily made the switch from VB6 to .NET or have selected Visual Basic over C# for .NET development. Please do contact me if you would be happy to do this. Thanks.

Richard, could you just say a few words about your role in Financial Objects?

I am chief architect and product director for our Microsoft platform retail banking solution: activebank. I also provide architectural and technology strategy support to other product teams as well as advising the board on technology matters. I have worked with the activebank solution for 14 years now and have followed Microsoft’s enterprise technologies and more importantly, Visual Basic, through that period. In my role I am concerned with the entire development lifecycle, including post-deployment support, which I believe brings a healthy dose of caution and realism when considering the adoption of new technologies, methodologies and approaches. We operate an on-shore / off-shore model for the development and support of this product and this arrangement has provided me with fantastic opportunities to focus on the processes as well as the nitty-gritty day-to-day technology of coding.

I understand that many of your products started out using Visual Basic 6 and earlier. When you decided to move to .NET did you consider also moving to C#?

We certainly considered all of the dishes that were on the Microsoft menu at the time .NET was introduced. We were fortunate to be working with Microsoft under a Premier Support for Developers agreement (PSfD, now Microsoft Partner Advantage – MSPA) at the time, which gave us privileged access to those in the know and for us to be able to have frank and open discussions about the variances between the languages.

The demonstration of the MSIL generated out of the languages was enough for me to understand that we would not be making a technical compromise by choosing to stick with Visual Basic, and so we were free to make the decision on the basis of what suited our organisation best.

Given that we had a large and capable team of Visual Basic developers, a large repository of Visual Basic source code that needed to be supported, and a healthy backlog of work to deliver, the decision to move ahead with Visual Basic was a fairly trivial one for us!

Do you have any regrets about deciding to go with Visual Basic .NET?

I regret that Microsoft did not do more to make VB.NET appear cooler and sexier to developers than C#. The result has been years of developers jumping to the conclusion that C# is the more a able and comprehensive language than VB when that is so clearly not the case. For us, this meant that we had some casualties in the early days in terms of experienced developers jumping ship to work with C#.

But, other than that minor gripe, no real regrets at all.

What approach have you taken to moving Visual Basic 6 applications onto .NET? Did you create or buy any tools to help you?

We were fairly masochistic about it. We saw the re-engineering to .NET as an opportunity to make some worthwhile advances with our application architecture and development processes, rather than taking a sausage-machine approach to getting onto .NET. Consequently, we built a new application framework from the ground up; we re-designed our use of modelling in the development process; and we produced the patterns we needed to be able to integrate both new .NET components and existing COM component in the same deployment.

What would be your advice for a company with a significant investment in VB6?

“Don’t Panic!” I feel that there has been an growing amount of uncertainty perpetuating around our industry, and consequently among our customers, regarding the implications of operating a strategic solution that may be built in part or completely from VB6 code. This has resulted in some “from the hip” demands that software vendors immediately address the “problem” of supplying a solution that is built with an “unsupported” development product.

My advice is that anyone responsible for a strategic solution that is in part or whole VB6 must now set themselves a target as part of their product roadmap to engineer out the remaining VB6 components. They must not feel pressured into removing the VB6 code in any radical way, though. They have time to do it the way that works best for them, their team and their customer. The old adage “don’t bite off more than you can chew” applies here: deal with the re-engineering of the VB6 code as a requirement in its own right. Don’t be tempted to re-architect from the ground up right now (unless that was on the roadmap already and you can afford to put product development on hold for some time).

And finally, what new technologies from Microsoft are you most looking forward to using in the future?

Visual Basic 10. Visual Basic 11. Visual Basic 12...

Entity framework is looking like a ‘worthy of a prod’ type of technology, so I’m looking to get that at least into a lab environment to see what it can do for us in more detail, along with the associated goodies like ADO.NET data services. Team Foundation Server, while not really in the ‘new’ category, is still in the process of being adopted across all of the projects and so I am working to get that up and running across the board. As a distributed development shop it clearly has lots to offer us. The 2008s (Windows Server, SQL Server and Visual Studio) are all foundations of the work we have in the development shop now that will be deployed in the next product release. Business Intelligence is an area that we are interested in right now and can see that the current offerings from Microsoft in this area could help us to deliver some smart solutions. Lastly, we care keeping an eye on the ‘user experience’ space to work out what improvements we can make to our user interfaces without just adding bling for the sake of it.

There’s lots going on and it’s a good industry to be involved in as much as ever, if not more so.

Note: We did this interview several weeks back and for some reason it “escaped” my Inbox into a sub-folder without ever making it onto this blog. I only just rediscovered it whilst unsuccessfully trying to find it on this blog! Sorry.

Rewrite vs Migrate vs Reuse vs Replace

Eric Nelson — Mon, 03 Nov 2008 16:59:38 GMT

“Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005” is a great resource for anyone looking at upgrading from VB6 to .NET. The guide was developed jointly by the Microsoft patterns & practices team and ArtinSoft. See my interview with ArtinSoft CEO Roberto Leiton Garro. It was written some time back and things have moved on – but it still represents a great source of information.

One of the first issues the guide addresses is the question “Should we upgrade?”, neatly summarised by this diagram.

The four options are:

Migrate. Automated migration process using Visual Studio or 3^rd party tool.
Reuse. Interoperate – extend and upgrade.
Rewrite. Start over.
Replace. Look for a package solution or outsource.

Many companies I worked with in the early days of .NET looked first at Rewrite driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects run into difficulty and several were never completed. The problem they were trying to solve was too large:

Clean/improve the architecture and codebase and
Be competent in a completely new development stack on a large project from day one and
Simultaneously add additional new functionality to justify to the business the time and effort expended and
In many cases also introduce new software development practices.

Hence I quickly became a fan of Migrate or Reuse as the right approach for most companies. Interestingly though, Rewrite is a less risky option than it once was. Many companies who still have significant VB6 projects also now have strong .NET skills gained on other projects, improved software development practices (including automated tests – a must IMHO for Rewrite) and have even taken the time to refactor elements of their VB6 codebase over the last 6 years. That said, I would still place Rewrite below Migrate or Reuse for most companies.

Moving from VB6 to VB.NET – time for a poll…

Eric Nelson — Mon, 03 Nov 2008 16:30:06 GMT

Back in April I posted a summary of some of the resources I’d found which look useful to anyone involved in the move from VB6 to .NET. Over the next few weeks I’m going to dig into this whole area in a bit more detail, starting with a bit of reading. I’m also going to find out what’s new or changed in the upgrade options that are available to VB6 developers in Visual Studio 2008.

I would be interested to know what people are currently up to with their VB6 applications.