The Visual Basic Team : Todd Apley

InteropForms ToolKit - Visual Studio 2008 edition (Todd Apley)

VBTeam — Wed, 05 Mar 2008 17:51:00 GMT

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!

With that pitch out of the way ;-), let me now go into detail about the specific items I mentioned if you want to use the interop toolkit with VS 2008. When we released the toolkit, we weren't able to fully test it out since VS 2008 was in beta, although we did get most of the core scenarios working. That being said, here are things you should be aware of:

Installation:

Side by side installation. If you have VS2005 and VS2008 installed, if you install the tookit, it won't register for VS2008. If you really need this functionality, add a post to the interop forums and I'll post up more details on how to make this work for you. However, in general, you should just uninstall VS2005 since VS2008 is able to work with both types of projects and then run the interop toolkit setup again.

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):

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!
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.
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:

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.
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:

Create a public method in your usercontrol project that calls the dispose() method in your usercontrol.

In the queryunload of the form that's hosting the control (or in some other reasonable place) you call this method.

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:\wherever\rc.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 Library.zip”, “VB6 UserControl.zip” 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!

Toddap_MS

Channel 9 Interview - Tips and Tricks with the Interop Forms Toolkit (Beth Massi)

VBTeam — Wed, 05 Mar 2008 09:23:00 GMT

Today I posted a Channel 9 interview with Todd Apley, Senior Test Lead on the VB Team, where he shows us a variety of tips and tricks with using the Interop Forms Toolkit on Visual Studio 2008. He also shows us how to deploy a hybrid application built with VB 6 and VB.NET using XCopy deployment and RegFree-COM.

Todd will also be posting follow-up information here on this blog. Also, check out interop posts here, articles on my blog on interop as well as the rest of the VB Team Interviews on Channel 9.

Enjoy,
-Beth Massi, Visual Studio Community

InteropForms 2.0 Tip #1 - Font Property

VBTeam — Tue, 05 Jun 2007 02:55:00 GMT

(Starting today, we'll be highlighting various tips that might help you when using the InteropForms 2.0 toolkit. With the latest release of the toolkit, you can do some fairly impressive upgrades to your existing VB6 applications. Don't believe me? Check this out as one cool example - WPF in VB6 anyone?!)

If you don't have it, you can download the toolkit here.

Adding Font Property:

Here's a tip on extending Interop Usercontrols that some of you might find useful. Most usercontrols have a "font" property associated with them which can inherit its values from its container and defines what font is used for the controls that it contains. If you want to add this support to your control, here's what you can do.

1) From your VB6 Interop Usercontrol project, goto the references dialog on your project and add a reference to "stdole"

2) Open up your interopusercontrol control and in the "VB6 Properties" region, add this code:

Public Shadows Property ControlFont() As stdole.IFontDisp

Get

Dim fntTmp As New Drawing.Font(MyBase.Font.Name, MyBase.Font.Size, MyBase.Font.Style, _

System.Drawing.GraphicsUnit.Point, CType(0, Byte))

Return ActiveXControlHelpers.GetIFontDispFromFont(fntTmp)

End Get

Set(ByVal value As stdole.IFontDisp)

MyBase.Font = ActiveXControlHelpers.GetFontFromIFontDisp(value)

End Set

End Property

3) Open up ActiveXControlHelpers.vb and add this code to the activeXControlHelpers class

Friend Shared Shadows Function GetFontFromIFontDisp(ByVal obj As Object) As Font

Return AxHost.GetFontFromIFontDisp(obj)

End Function

Friend Shared Shadows Function GetFontFromIFont(ByVal obj As Object) As Font

Return AxHost.GetFontFromIFont(obj)

End Function

Friend Shared Shadows Function GetIFontDispFromFont(ByVal font As Font) As stdole.IFontDisp

Return TryCast(AxHost.GetIFontDispFromFont(font), stdole.IFontDisp)

End Function

4) You can then compile your project and reference it from VB6 and set the "controlfont" property appropriately.

This property was not included in the InteropForms 2.0 release since we didn't feel like it was that common of a scenario and it can make deploying the control in the general case a bit trickier. Specifically, you need to ensure that stdole.dll is deployed in the GAC which you can install by running a setup called vs_piaredist.exe which should be installed on your machine that has VS (typically in a \program files\common files\merge modules directory). It's a silent install, so it's pretty easy to deploy. However, you may find that all your clients have this installed and you don't need to worry about this.

Deploying Applications with the InteropForms 2.0 toolkit

VBTeam — Tue, 05 Jun 2007 02:46:00 GMT

(Recently, we released the InteropForms 2.0 toolkit which allows you to add the richness of .net windows forms to your vb6 application. We've gotten a fair number of questions from customers asking for more details on deployment, so this will hopefully answer most of your questions)

As I'm sure you're aware, deploying VB6 COM based applications can get complicated at times, which is one of the great advantages that moving your applications to .NET gives you. The Interop Forms Toolkit 2.0 allows you to easily extend your VB6 applications with .NET functionality, which is great, but it creates some interesting deployment issues. The good news is that there are some things we did in the latest 2.0 release to make this much easier than before and we tried to document the different strategies, but given that there are plenty of ways to do things, we wanted to blog about this in more detail.

To save you some time, here's what we recommend in general with building mixed apps.

a) Use the Interop Forms Toolkit to build Interop Usercontrols instead of Interop Forms.

b) Remove the reference to Microsoft.InteropForms.dll library unless you plan on taking advantage of some of it's functionality such as the Globals class (for sharing state) or the EventMessenger class (for raising application-level events).

c) Configure your usercontrol manifest appropriately and create an application manifest for your VB6 app so you can take advantage of Reg-free COM

d) Modify your legacy setup to copy over your new usercontrol binary and the application manifest into your application folder.

If you can do this, you can easily augment an existing application in a painless way. Deploying an application created this way is as simple as copying the new files down into the target directory. Of course, this doesn't work for all situations and I've glossed over a few other details that should be mentioned. To decide on the best way to deploy your application, you have to deal with three issues.

1) Prerequisites:

If you use an Interop usercontrol/form in your project, your clients need to have the .NET framework 2.0 installed on their system. This framework is on machines by default in Vista and may be on your client machines anyway, but if not, here's some options. (This assumes you have permissions to install/rollout .msi setups that globally effect the machine.)

1) The recommended approach is to use the bootstrapper technology in VS 2005 to deploy any prereqs you need. You can create a custom bootstrapper which installs prereqs like the .net framework only if necessary and in a secure way. These prereqs that the bootstrapper supports are typically called "bootstrapper packages" and you can see what's available on your machine by going to the Publish tab in the project designer and clicking on "Prerequisites" button.

A "custom bootstrapper" is basically a special "setup.exe" that is built by VS that understands what prereqs are needed for your application. Once the prereqs are installed, it will launch whatever you want - typically the application setup. If you ever build a Setup and Deployment project in VS or publish a Clickonce app, the "setup.exe" that is created is a custom bootstrapper.

2) Alternatively, you can roll your own approach (use batch file, etc...) which I won't go into detail here.

For most .Net created apps, the .Net 2.0 framework is the only dependency you have. However if you use InteropForms (rather than Interop Usercontrols) you take an a dependency on a binary called the "Microsoft.InteropFormTools.dll". You also have this dependency by default if you create an Interop UserControl project, although you can safely remove it unless you explicity want to use some of the objects in this assembly. We have bundled this file in a redist package and created a bootstrapper package so you can safely and securely deploy this binary just like you would with the .Net framework.

Lastly, if your Interop project has any extra 3rd party dependencies, you'll need to ensure those are appropriately installed. If you want, you can create your own bootstrapper package for them and have the VS bootstrapper take care of installing them for you.

Resources:

Creating a custom bootstrapper: Check out the "How To: Deploy a Hybrid Application" topic in the Interop Forms Toolkit documentation.

Creating a bootstrapper package: Check out these links:

http://msdn2.microsoft.com/en-us/library/aa730839(VS.80).aspx

http://blogs.msdn.com/chrsmith/articles/Using_the_Bootstrapper_to_wrap_a_Windows_Installer_package.aspx

Actually, there's a great tool that David Guyer created to allow you to visually create both a custom bootstrapper or a bootstrapper package. I highly recommend it. You can download it (via ClickOnce!) here:

http://www.codeplex.com/bmg

2) Registering the Controls with Reg-Free COM:

Registration free COM is a cool technology that works in Windows XP and later operating systems that allows you to deploy COM-based binaries without having to register them. If you can be sure that your clients will be on this platform or later, then it can make your deployment story much easier if you use Interop UserControls. As I mentioned above, the only thing you need to add to legacy application is add your new usercontrol assembly and an application manifest file to your application and copy those files to the application directory and you're done.

If you use InteropForms projects (or say you have to support older platforms like Windows 98 or Windows 2000), this approach won't work and you'll need to use regasm (or a windows .msi) to deploy your assemblies which is more difficult, but still quite doable. If you use InteropForms projects, probably the easiest way to deploy them is in this manner:

1) Create a VS Setup and Deployment project and add your InteropForms assembly to it. Also, make sure you set the register property to vsdraCOM so that will get globally registered on the machine and build your .msi

2) Create a bootstrapper package for this .msi and then add this package to your custom bootstrapper.

Interop UserControls projects cannot be deployed this way b/c they rely on some additional code to get run to register them properly (check out the code in the method with the DllRegisterFunction() attribute), so you need to use regasm.exe directly if you want to deploy them and cannot use reg-free COM.

Note: If you do need to use regasm.exe, what I find to be the best approach is to create an .msi like above, but use a custom action to register/unregister the assembles. The good news is that we've shipped the code to do this and you can just borrow what we have. Look in the source.zip file in the installation folder and check out the "bootstrapperpackageinstaller" project for details. In the "How to: Deploy a Hybrid Application" in the Interop Forms documentation, we also mention that you can ship regasm.exe in your installer, although I would recommend using the code that we ship (which searches for and finds the right copy of regasm.exe installed locally).

Resources:

Search MSDN for "vsdraCOM" and you'll get a bunch of information around this. Also, check out the links mentioned above for more information on bootstrapper information.

3) Your existing setup:

Part of the choosing of the best way to deploy your application comes from what you can do with your existing setup. Here's the common scenarios and what we recommend.

a) Your setup is frozen (or you cannot modify it).

In this case, you can create a custom bootstrapper to install all prereqs that your application needs (whatever component you created in (2) above).   You will end up with a single setup.exe which will launch and setup everything the application needs.

b) Your setup is a windows .msi file created in VS.   In this case, you can just add the appropriate logic for installing your assembly (see (2) above) and you can just goto the Prerequisites dialog for the setup project and rebuild your .msi.   VS will create a custom bootstrapper (the setup.exe) that installs all needed prerequisites.

c) Your setup is created with the VB6 package and deployment wizard or some other technology and you can modify it.   Depending on (1) above - namely, if you need to install prerequisites, you might want to create a custom bootstrapper to "wrap" your legacy setup.   Depending on (2), you can either just add your files to your setup (if you use RegFree COM and Interop Usercontrols), or can do something custom for your setup.

Resources:

http://blogs.msdn.com/chrsmith/articles/Using_the_Bootstrapper_to_wrap_a_Windows_Installer_package.aspx

Anyway, I hope that helps clear up any confusion around deploying hybrid applications. If you run into questions/issues feel free to ask questions here and we'll do our best to help you out.

Also we'll be doing a webcast with demos and some Q&A on June 6th, you can register for it here: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032337474&EventCategory=4&culture=en-US&CountryCode=US

Good luck!

Toddap_MS