InteropForms ToolKit – Visual Studio 2008 edition (Todd Apley)


I apologize right away that it’s been a while since I’ve blogged about the interop forms toolkit although I’ve been doing my best to keep up with issues and questions on the interop forums.   It seems from the mail I’ve received that a lot of people are having good success at extending their legacy vb6 apps in interesting ways using the toolkit.  This post is a follow-up to the channel9 video that Beth posted here.

What’s New – VS 2008

I wanted to use this posting to describe in more detail some of the content that I covered in that video.   The main focus of the video was to describe how with the release of Visual Studio 2008, what changes should people be aware of when they are using the toolkit and what advantages there are with upgrading their development environment.

Why use Visual Studio 2008?   Part of the goodness of being a tester at Microsoft is that you get to play with technologies several years before they are released.   I can certainly say that if you are using VS 2005 (or before), you’ll really appreciate using VS 2008 even if you don’t take advantage of any of the new cool language features such as LINQ and XML literals.   Specifically, you’ll really notice the work done to make intellisense and performance of the editor far better than we have ever had it before.   Anyway, I occasionally have to use older products (to track down bugs) and I pity the people who aren’t already using 2008.   Feel free to download the Express product and try it out!

Update (4/13/10):  The 2.1 version of the toolkit now fully supports VS 2008 and VS 2010, so install this version if you are using one of these versions of VS. 

Developing your .NET code:

Once you have the toolkit installed, you should be able to develop your interop usercontrol or forms project as normal.   However, be aware of the following (learned from hours of doing things the hard way):

  1. First, when you create your usercontrol project, create the project with a uniqueish name and then save the project.   If you don’t, you can easily run into odd problems with COM progID collisions and it makes it easier to mess up RegFree COM settings.   In fact my channel9 video nearly didn’t work b/c I just used the default name it gave me and I had already created a project of this name on another machine that I was trying to run the application on.  Ack! 

  2. Target frameworks.    When you create an interop usercontrol/forms project, the target framework will be set to 2.0 which means that you won’t be able use things like LINQ in your project.   To change this, just goto the compile properties tab/advanced compiler options page and change the target framework to 3.5.   You may have to then add some references link system.xml to your project, although in general the VB compiler gives pretty good warnings/errors when you are missing appropriate references.   

  3. As mentioned in this post, the recommended way to develop hybrid applications is to use interop usercontrols and not not use the microsoft.interopformstools library unless you want to take advantage of some of its functionality (such as exposing application events and sharing global state).   Consequently, I recommend you remove the reference to this assembly after you have created the control and when you do, compile your project -> you’ll get a compile error in the activexcontrolhelpers.vb file where there are a couple of references to this assembly.   Remove the entire “namespace my” section from the code and you should be fine.   Of course, all good tips bear some appropriate disclaimers, so I’ll do the same.   My recommendation to always use interop usercontrols is valid except in these situations:

    1. Where tabbing keyboard access between then host control and the interopcontrol is critical.  There are some known oddities where tabbing doesn’t work properly in these cases.   Start doing some basic prototyping and see if it works well enough for you.

    2. Where entry of DBCS characters is needed in the interop usercontrol.   There is a known bug on this which hasn’t been fixed yet.

If you run into other bugs/problems, issues, the best way to get resolution is to search the interop forums or ask your question there.   If you want though, you can contact product support as the interop toolkit is supported as well.

3. Loading/Unloading of forms:   If you place an interop usercontrol on a VB6 form and that form is repeatedly loaded and unloaded in your app, be forewarned that there are known issues in unloading releasing the usercontrol from memory, although it’s easy in most cases to workaround.   If your app has this type of behavior, what you should do is the following:

  1. Create a public method in your usercontrol project that calls the dispose() method in your usercontrol.
  2. In the queryunload of the form that’s hosting the control (or in some other reasonable place) you call this method.
  1. When building a usercontrol project, be aware that even though it may say it compiled and build ok, it may not have entirely worked.   There is a post build step that uses rc.exe to compile icon and manifest information into the assembly and the logic for this post build step does not work on VS 2008 due to a change in where they store rc.exe.   You can see the post build step logic by going to the compile properties tab/build events dialog.    Basically, you just need to adjust the logic in this event to point to where rc.exe is located on your machine.   Here’s an example:

“d:whereverrc.exe” /r “$(ProjectDir)InteropUserControl.rc”

After you change this, recompile your project, and look in the “output window” to ensure that this step isn’t failing.

Changing these settings for good:

Doing the 4 steps above isn’t really that hard and most of you probably will not develop too many of these controls, but if you find you want to automate/change the above for good, it’s not that difficult to do so.   I’ll explain briefly here what you can do to change this.   If you want more information, please make a request on the interop forums.

1.     All the project settings are stored in various template files.   You can see where the templates are stored by going to tools/options projects & solutions and seeing the “user project templates” and “user item templates” locations.   If you look in those locations, you’ll find a “VB6 InteropForm”, “VB6” file (and you’ll also find similar files in the item project template location).   All you need to do in general is

a.     Create a backup of this file (in case something goes wrong)

b.    Unzip the file

c.     Edit the appropriate .vbproj file (e.g. you can copy appropriate lines from a VS2008 project file that you use often and copy them over to the template location)

d.    Rezip the file and place it in the same location (you can give it a different name if you want)

2.     At this point, if you restart VS2008, and choose your new template, it should use your new settings.

Hopefully, the above made sense and should be easy for you to do, but if not, ask away on the forums.

Consuming your .NET control from VB6:

This is a biggie!   Regardless of whether you use VS 2005 or VS 2008, you’ll want to be aware of this if you create usercontrol projects.    There was a bug in the .net framework which prevented VB6 from syncing events on usercontrol projects.   We documented a workaround in the help we shipped which explained how to work around this.   However, the good news is that this bug is now fixed in .net framework 3.5 or in the 2.0 SP1 framework (which you can get here), so you can consume .net interop controls in the same way you would do any other ActiveX control in VB6.   Additionally, this leads to some other scenarios that weren’t possible before (such as you can now have a vb6 usercontrol which hosts a .net usercontrol, etc…**), so please be aware of this change as the docs are now out of date.   Of course, you’ll need to ensure your clients have the patched framework as well.   I’d add some demo code here, but I don’t think it’s necessary.  If you are used to working with controls in VB6, you already know how to make it work.

**Make sure you read my “Developing .NET code section above for some caveots with this approach that might effect you.

Also, as I mentioned in the Channel9 video, I think the slickest way of developing these usercontrol projects is (from VS in your interop project), goto your debugging properties page, choose start external program and point it at where you have vb6.exe locally.   You can then simply press F5 and VB6 will launch and you can do things like setting breakpoints, etc…   Just be sure to remember (as I didn’t in my demo 😉 ) that if you stop debugging from VS, you will lose any unsaved changes in VB6.   Always make sure you save any changes in VB6 before you stop debugging!

Deploying your application:

The best article we have for understanding everything w.r.t. deploying interop projects can be found here.  I’m confident that if you follow the guidelines there, it will help you deploy these applications in a painless way.  If you have questions/concerns, look on the interop forums or post a question there  (although I’ll monitor any comments to this post as well)

Also, if you search around, you’ll find a lot of interesting articles written by people doing things with the toolkit.  For instance, here’s a good one on using my.settings with usercontrols.

VB6 – Live long and prosper…

Anyway, I know that many of you feel that VB6 is a dead product and although it’s starting to certainly show its age, I think there’s still a lot of life left to it.   Heck, I even continue to use it in my job regularly for some internal tools we maintain.  With the interop forms toolkit, it gives you the developer a straightforward way to start slowly incorporating .net functionality into your apps and learn new skills w/o losing the investment you already have made in your application logic.  

Good luck!



Leave a comment

Feedback usabilla icon