Question about development choices

[whopis04]

Greetings all,

I have been trying to determine the best strategy for a project that we are about to undertake and would like to get some feedback from the people here.

We are in the process of beginning a major redesign of an existing software product. The current version was developed (mostly) in Visual C++ 6.0 as an MFC based app. In general, there are 3 ways that our customers use the app:

1: Through our front-end. Basically, it is a windows application, pretty standard stuff.

2: Through a DLL that we provide to give access to the back-end operations of the software.

3: Through COM automation that our application provides.


I am currently trying to decide what is the best strategy for the redesign.

We have a great deal of C++ experience in house and would prefer to stick with that language as much as possible.

We want to have both a good UI-based product as well as a solid back-end component that our customers can use to power their applications.

The majority of our customers who use the component-based product are going to be developing their apps in VC++6.0 or VB. A smaller (but probably growing) group will want to use .NET.

What is the best (or at least some good) idea for supporting all of this? I would like to see at least the front end developed in VC++.NET, and potentially as much of the back-end as possible as well. However, it is critical that we have a product that can easily be used in VC++6.0 or VB (not .NET) applications (both as a DLL and COM server).

Are we better off designing it around a standard DLL on the backend that is then wrappered to provide .NET access and develop the front end in VC.NET, or to do things the other way around? (Meaning develop it natively as a .NET application and create wrappers to support the old DLL and COM interfaces).

Basically the problem comes down to this:
I would like to take advantage of .NET as much as possible (particularly in the front end UI side of things) and I think our customer base who wants a component product will start moving towards .NET, but we have a significant amount of users who will demand a product that can be used in existing systems without having to redesign all their software.

Any help would be greatly appreciated.

Thanks,
dan

[darwen]

Did you know that .NET assemblies can be registered the same as COM dlls and accessed through IDispatch interfaces ? Probably not.

Personally if I were faced with this issue I'd jump at the chance to rework the whole thing in .NET. With the advent of Vista (the new windows) managed code is going to gain in popularity exponentially. Most coporate banks, for instance, are certainly going down the .NET route with traditionally C++ companies following suit.

If I were you I'd get a copy of C# and start learning the language before you make your decision. It's impossible to make a decision based on non-existant knowledge : you'll soon find out that C# is a much nicer and cleaner environment and language to work in than C++.

Or at least I have. I was one of the C++ stalwarts who insisted that managed code could never replace good old C++. Until I tried it out : and from that point onwards I was totally hooked by the niceties of the language and its power to produce truly elegant object oriented designs.

But you surely can't ignore the way that the world is going. Certainly traditional MFC programming is giving way to .NET, so I'd try it if I were you.

Darwen.

[whopis04]

I was aware that .NET assemblies can be exported as COM DLL. That will work fine for our users who are using COM, but unfortunately, we have to support a significant number that are using a plain old DLL interface. And while banks and other companies might be going down the route of .NET, I know that a significant portion of our customers are not going to be doing that for quite some time to come. And while I would like to see all of the application be in one language/framework, that simply won't be possible (until you can write kernel drivers in C# at least...)

I certainly have no love for MFC and don't have any problem getting away from it. In fact, I had already decided to do all of the UI layer with forms instead of MFC. The choice of managed C++ or C# isn't that significant to us right now though.

I guess my biggest concern is this: If I have to support customers that are going to use a traditional DLL interface (not COM) for a non-UI back-end system, is it going to be easier to do that by wrapping a traditional DLL to be used by .NET, or by wrapping a .NET assembly to be used through a DLL?

[darwen]

Personally I think you're throwing the opportunity of using managed code in the bin for the sake of a few users who use static dlls. I'd write a static dll to wrap the managed code if I were you.

Why don't you just go and experiement ? The forums are always here for if you get stuck. Personally I worked out how to do all the necessary things (IUnknown-COM interop etc) before we started work on the managed version of our app - just so as I knew what pitfalls we might encounter.

Darwen.

[whopis04]

I think that I may not have asked my question clearly... but you may have answered it anyway.

The only thing that I was really concerned about was if it was feasible to write a static (non-COM) DLL interface around a .NET assembly. I'm not at all concerned with any difficulties developing the app in C#, mangaged C++, or whatever... I just needed to make sure it was possible to wrap a .NET app in a DLL that wouldn't force the users to use COM.

It, unfortunately, is not just a 'few' users that need the DLL. It is a significant portion of our customer base. And I have no reason to believe that they are going to change any time soon. This is an industrial application and it wasn't that many years ago that we had to drag these guys kicking and screaming away from DOS. Legacy support is a huge part of our business (for better or for worse).

Anyway, from what you have said, I gather that it is feasible to do that. That is most likely the direction that we will take.