Thursday, August 17, 2006 7:29 PM
We have a VB6 app that we've used the upgrade tool to upgrade to .NET. The original VB6 project was an ActiveX EXE, with windows forms as the primary code components.
This proejct is not working since we've updated it to VB.NET - the EXE is not available to be called through COM as a COM object, nor is it being registered in the registry.
What do I need to do to my project so that it runs the Windows Forms that I need (with the code in them) and yet still be able to call it through COM from other applications?
I've seen the references to using the COM Class template, yet i'm not sure how to integrate it into my application with Windows Forms in it.
Thanks for any help you can provide!
Thursday, August 17, 2006 7:34 PM
I forgot to mention that the only thing we're using the COM part of the application for is to launch the application - so that when someone instantiates an instance of our application (which used to be an ActiveX EXE), we simply launch the application (or send it to the Sub Main code to run from there).
Friday, August 18, 2006 11:18 AMThere is no equivelent to the ActiveX exe in dotnet.
If all you need to do is launch it, then why doesn it need to be an axtivex exe, couldn't it have just been a normal exe.
Friday, August 18, 2006 11:36 AM
It needs to be an ActiveX EXE becuase the applications that launch it do so by using the prog id stored in the registry. The other apps store the prog ID and instantiate it like it was a COM DLL, but instead it's a COM EXE.
Any way I can do this? Have the EXE be registered in the registry with a PROG ID so that the other apps can instantiate it and use it like a COM object?
Friday, August 18, 2006 2:32 PM
Is there a reason why it has to be an (out-of-process) EXE as opposed to a (in-process) DLL?
UPDATE: Scratch my question I just realized it's an application and not a component.
Friday, August 18, 2006 2:37 PMUnfortunately, yes (is there a reason why it has to be an (out-of-process) EXE as opposed to a (in-process) DLL), the code is a windows form application that gets called/launched by these external apps, using the GUID stored in the registry from when the ActiveX EXE was registered. We can't put everything into a DLL as we have serious windows (UI) functionality in a number of different forms.
Friday, August 18, 2006 3:00 PM
Yes, I didn't realize this was an application with a UI.
Can you change the method by which the application is launched? Is automation required?
Friday, August 18, 2006 3:06 PM
Unfortunately, automation is required by the other apps, so we're getting pretty desparate around here. No time to totally restructure and change the applicaiton, so i'm trying to somehow jury rig things to work.
Problem is we also use COM objects from the calling apps, and have to implement some COM interfaces from those app's COM objects - right now, that COM interaction isn't working at all, becuase our app can't do the handshake correctly due to it not being an ActiveX EXE.
Our app is actually launching due to it overwriting the older VB6 version, so the calling apps are using what's left over in the registry from the prior version to actually launch the app. But it's that COM handshake that's not working, so our app doesn't actually function once it's launched.
Friday, August 18, 2006 3:53 PM
OK, well I'm not really sure what sort of COM automation support is required (other than for launching your application).
If automation is limited to launching the app, but you still need the COM mechanism because that is what the client applications expect, you could just use the ActiveX EXE as a stub process which shells out to your .NET application. The only function of the ActiveX EXE then would be to launch your application.
Now, if you need to automate the functionality of the standalone .NET application I'm afraid that there isn't a way to do this that I am aware of.
Friday, August 18, 2006 4:20 PM
OK, your mention of com class templates triggered something in my memory that I apparently had forgotten about. You can create COM classes in a .NET EXE and reference them via interop. See if the following articles help:
Saturday, August 19, 2006 4:31 PMOwner
Paul's approach should solve your problem.
To make it fast and easy we're working on a toolkit that makes it easy to show VB.NET forms easily from a VB6/COM application. E.g. you could change your new VB.NET application to a VB.NET control library DLL (just change a project setting), add a few <InteropForm> attributes, and then you could have a thin VB6 activeX .exe to just host your VB.NET forms. This would require little rewriting. The only downside is you have a little bit of VB6 code to maintain.
If this approach sounds interesting I can give you an early preview of the toolkit to evaluate for your app. My alias is firstname.lastname@example.org (removing "online.").
Monday, August 21, 2006 2:33 PM
Thanks for everyone's suggestions - unfortunately, due to our limited development window, we've had to abandon all of our .NET code for this application, and have to go back to VB6 code for our next release.
We'll continue to work on the issue, and either wait for Studio 2005, or migrate some of the code into a web based application.
Thanks again for your help!!