0

This is a question about design approach. I have limited COM experience and a little WCF experience. My constraints are given by the application environment, but I have some design flexibility.

From within a VB6 dll, I need to start, and communicate with, a WPF application. The WPF application is currently an exe, but I could make it a library if that helped. I would like to provide two way communication between the VB6 dll and the WPF application. I have some flexability to adjust the design of the VB6 dll.

I'm developing C# using in VS2010 and .NET 4.

How many components should I use? Can I start the WPF application In-Proc with the VB6 dll? Should there be a third component between them? Can COM+ play a helpful role? Do I have to make the entire WPF application COM-visible? Is there a down-side to doing this?

I'm looking for a design approach that I can prototype. I'm willing to research the details.

JimBoone
  • 554
  • 1
  • 7
  • 27

3 Answers3

1

Out of the options available I like the COM option more than the 'start another process' option for the simplicity that the inter 'application' communication will be via method calls rather than WCF or anything similar.

I am assuming that your VB DLL lives in a window'd process and not a service or web application. You would only need to mark any exposed types as COM visible, that is the classes, their argument and return types.

You may have to wrap your WPF UI inside the windows forms ElementHost [1] but I'm not sure, try it and see.

I'm not sure if you saw this [2] in your search, it sounds do-able but unsupported, ok as long as you don't have too much going on.

[1] http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.elementhost.aspx

[2] http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7555ba6a-1359-4dfe-aa23-c31a8f121142/

Adam Straughan
  • 2,766
  • 3
  • 20
  • 27
1

I would

  1. Create a Web Service from the WPF application, using WCF. I would abstract out those aspects of the WPF application which should be accessed remotely. This would explicitly not include any of the user interface code.
  2. I would create a simple class library project, and use "Add Service Reference" to add a reference to the WCF service.
  3. I would make the methods of the class library COM-visible
  4. I would call those methods from VB6

This has the benefit of removing any considerations of user interface from the equation.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • Referring to your comment, this is a real question for me. – JimBoone Aug 13 '12 at 23:20
  • For clarification, you're suggesting to add a third component that exposes COM method calls, and communicates with the WPF application over a service channel. Do I have this right? – JimBoone Aug 13 '12 at 23:25
  • What starts the Web Service? This whole set of stuff runs on individual user boxes. Does the Web Service start when it is accessed? – JimBoone Aug 13 '12 at 23:27
  • No, I would extract the "service" logic from the WPF application into a web service. That service would be called by the WPF application and by the VB6 application. – John Saunders Aug 13 '12 at 23:48
  • This solution path, suggested above, worked. I created a WCF service library to hold all the communication definition. I then self-hosted that library in the WPF application and tested it with WcfTestClient.exe. I already had a COM-visible dll that interacted with the VB6 dll, so I added a ServiceReference to the WCF self-hosted application from the COM-visible dll. Now the COM-visible dll starts the WPF application that self-hosts the WCF named pipes endpoints. I had to implement a "host-close" method so the WPF application new when to close itself. John, thanks for the help. – JimBoone Sep 04 '12 at 14:09
1

I work on an application primarily written in VB6 but most of the recent code is written in .net with UI components built in WPF and some WinForms. Datasources for this application are WCF, MSSQL server, and a propritary unix based server. All the WCF calls are made from data access components referenced by the .net UI components.

You can host WPF in VB6 windows or other container controls. Start by getting the Interop Forms Toolkit and build shell user controls to host your WPF controls.

To be able to host WPF in these controls you need to build a WinForms usercontrol which contains a ElementHost, which you can set the content to your WPF usercontrol.

WPF Usercontrol
inside an
Element Host
inside a
WinForms usercontrol
inside a
VB6 usercontrol or window

The interop toolkit will want to build VB.Net code but you can do it in C#, although I have not tried this. The usercontrols created by the interop toolkit will be exposed as COM components which you can reference VB6 by adding them as components via Project > Components and then you will find them in the toolbox.

In terms of data sources (WCF, databases) etc, you should build all your data access in .net components referenced directly from the UI components, don't try to call back in to VB6 libraries, you will probably just create a mess.

In my application I also have a configuration section which I call from the VB6 application startup which sets up an IoC container for all the .net components.

From a best practice approach I actually would recommend rewriting your VB6 code to .net and putting VB6 out of the picture. If this is not an option then you have a number of options, my explanation is just one of them.

benPearce
  • 37,735
  • 14
  • 62
  • 96