views:

38

answers:

2

I am trying to migrate a simple WinForms app to a ASP.Net web app. WinForms app is basically only a presentation layer for a complex plain C app, and interacts with legacy code through COM interop. I have modest experience in ASP.Net, javascript, jQuery, and lots of experience in WinForms and interop, so I know the basics, I just need to make a design decision.

The way the app looks right now is this:

  1. There is a bunch of legacy C (not even C++) code which can be changed and recompiled, but porting is not an option. This is the business+data layer, call it what you want. I'll refer to it as legacy code.

  2. When started, legacy code instantiates a COM server which is used for presentation and user interaction. Presentation data is serialized and sent to this COM object ("I'm sending you some output."), and user interaction is achieved through cyclic polling ("Do you have some input for me?"). Not the prettiest solution but simple as hell.

  3. COM object is actually a .NET 2.0 WinForms app exposed as COM. This app also exposes some functionality to other .NET apps through .NET Remoting, but that is not so important also.

Although the system is rather complicated, WinForms app is really used for interaction only, so it's pretty easy to switch to web. What I am not sure is what's the best way to do the web server <---> legacy code interaction.

The first thing that comes to my mind (since I already have .NET Remoting implemented) is to expose the WinForms functionality to the Web part through local .NET Remoting, making it act like some sort of a proxy between legacy code and web app. I would actually only need the communication part, without forms. In that case, web app would have to access this functionality through .NET Remoting (locally).

Is it wise to have web app communicate locally to another app using .NET Remoting? Also, I could change the app to a Windows service, but would I still be able to expose its functionality through COM to legacy code?

What would be a better way to achieve this? Note that I can also make some modifications to the legacy code if needed.

+1  A: 

I think that one important aspect for you is the single-userness of a WinForms app and the multi-user-sessionness of web.

10 years ago I was involved in several web projects where we ran the business logic as COM objects (VB6) in MTS and later COM+. Letting those COM objects belong to sessions were a no-no, because if users come and leave a lot you could end up with a lot of resources tied up in unused but living COM objects.

I would suggest that you look into running your COM objects in Component Services. It might not be THE SOLUTION, but it is worth exploring.

Putting COM objects in Component Services is as close you can get to writing a windows service that is reachable through COM - something I would touch for all the x in y : where x is favourite food and y is favourite place.

.Net Remoting is wonderful, but mostly interesting as a communication device. I don't know if you are going to split up this in many servers, it sounds like a company internal application. I don't have enough details to be more specific.

Guge
Thank you for your response. I have no experience with Component Services, so I will check this first.
Groo
+1  A: 

It seems like you should try to look for away to simply reuse your simple WinForms code over ASP.NET infrastructure. This means that you will probably will not need to re-write the UI code but just use it as-is on some emulative infrastructure of WinForms over web.

Please see my immediate suggestion of a framework that does exactly that: http://www.visualwebgui.com/landing/wow.aspx

I hope this helps…

Thanks. But the GUI is so simple I don't have any problems with porting it to Web. The problem is that the WinForms app acts like a COM server for a plain C app, which is the one that actually instantiates it. This activation is what bothers me.
Groo

related questions