DotNet or non-DotNet or both???

well, basically, from my previous post under 'Self-Improvement', i mentioned that i wanted to concentrate on the dotnet.

however, recently i joined a company developing software using C++ on win32 and MFC. after a few weeks here, i found out that they don't have any intention to do any dotnet development and they are not planning to migrate or upgrade to dotnet. the reason is, the company has produced a number of dynamic linked library in C++ and so far their product working perfectly with it and they do not intend to change all those code to dotnet. well, i wonder why can't the dotnet integrate with the C++ DLL??? 

im not expecting the whole company to migrate to dotnet development and the fact is im not the boss, but i just feel like why can't some developer build their code in dotnet and some in C++ DLL and integrate together. isit hard or isit 'impossible' to do such a job? basically, they're very experience in developing their product but is this mean that they're not competent enough in the dotnet technology or are they do not bother too much about the dotnet framework? but they've been using the visual studio .net 2003 for a while and i heard that they even bought the new 2005 license to develop their product, then i wonder why such a waste getting such an expensive microsoft tools but do not make full use of it's features.

any dotnet integration expert here can give some comments.

thank you very much.

 

cheers,

eddykuan

What you are looking for is P/Invoke (Platform Invoke) to interoperate with existing Win32 libraries.

COM Interop focus on communicating with existing COM platform to exchange functionality (both ways). Microsoft Office with VSTO is probably one of the stronger examples of this.

Forgot to mention: given the setup of your company, the likelyhood of embracing .NET is via C++/CLI where there can be a mix-match composition of managed and unmanaged code. The transition route with C++/CLI should not be as severe an impact as that of C# or VB. I do not have a C++ background, so do not take what I have written as Law. Mileage will certainly vary from team to team for their native:managed code base ratio.

Well, it is not that VC++ and .NET can't integrate together.  Icelava has shared with you some of the useful resources to find out more about Win32 API invocation and the COM Interoperability of .NET Framework.

The reason why your company is not keen on moving onto VB or C# .NET is probably due to the requirements of the product.

You may want to bear in mind that not all kinds of programming tasks are suitable to be developed using .NET languages. Some products are better to be developed with lower-level programming languages such as VC++ as they always give you more flexibility and control.

Even if the product is feasible to be developed using managed code such as VB or C# .NET, we will still have to balance the cost of migrating existing components or the overhead incurred by the interoperating with existing components which were developed in unmanaged code.  Since most of the developers in your company are well versed in VC++, I would say it is a natural choice to stick with the same language even for the new products.

After all, human are creatures that resist changes.

I was at your situation back then when I was doing smart card programming. I agree with IceLava and Maung Maung that certain languages are better in certain scenarios.

Let me give you some tips to help you.

When I say C++, means classic C++

C++ Dll - you can use P/Invoke in C# to call it

C++ Lib - I doubt there is a way to call it using P/Invoke. You only can write a C++.NET Wrapper for this. Or you can rewrite from scratch.

C++ communicates with C# - you have to build a communication layer using C++.NET so that C# can speaks to C++. It is quite tedious to do this.

Last thing, whatever I mentioned above were based on .NET 1.1. So maybe now things are more transparent. I left those stuff long time ago.

actually, you don't want to move to .NET if you're doing windows-based application for two reasons

1. performance: just look the sorry state of visual studio 2005, document explorer and SQL management studio, and you will realize that the day for .NET-based windows application hasn't come yet. This problem is particularly amplified by the ease of writing sloppy code by developers who are introduced to .NET through very bad examples.
2. lack of OS-independence: granted that there is a lot of work in preparing C++-based app to run on more than just Windows, but the fact is that as soon as you go .NET, there is a much higher tendency to move away from the scary/error-prone C++/CLI stuff and stick with the programmer-friendly WinForm/WPF goodies. Once that switch is complete, it's impossible to move to other platforms without major changes.

In theory, you can do the backend (engine, core or whatever you call it) stuff in C++ for performance reasons and hand over the GUI to WinForms. But the outcome of Visual Studio 2005 tells us otherwise. Surprisingly, the reverse maybe what's coming. You can have C#-based services in WCF and C++-based app that interacts with them. (just like SOA smart clients but sans the WinForm)

icelava: i already tried the Platform Invoke kind of method to call those C++ DLL and this method works perfectly for some simple function that i use but not sure whether it's ok for those complicated function or not.


chuawenching: i dun quite understand the the difference between the C++ DLL and the C++ Lib and why we need a wrapper for this case?


feelite: sorry bro, i really dun quite understand your points here.


MaungMaung: i guess u have your reasonable points here. maybe my company's product is best to be develop using the good old C++ and so far from what i heard i guess our product is working perfectly fine. u also have your point on the migration from the unmanaged code to dotnet, well basically all their library is in C++, so i guess they won't gonna change all their library at this moment. another thing is, all the experience programmer in my company would face alotof problem later if ask them to learn dotnet. well when they ask me to learn the win32 and mfc which is quite new to me at first, i was also got my head big on it and dun quite able to accept it at first.


actually im not expecting my company would able to plan to develop a dotnet application in this short time as im not pro enough in this area as well. as i mentioned earlier, im not the boss la. so i was initially planning to continue to learn those mfc, win32 and get myself experience in a few SDLC, OOP and UML, in the same time get myself certified by microsoft, and then i will propose to my management to implement one dotnet application and from there will see again what's going on.


well, just now surprisingly, i got a positive feedback from my supervisor telling me that they might consider implement one of the server for my current project in dotnet if provided i can prove them this is feasible enough to develop by next week. so i guess i will have a tough day this weekend. i was quite shocked with this as earlier they were strongly objected to dotnet and i think maybe some of the management in my company read this thread. hahaha...

so what do u guys think about the feasibility of developing the dotnet application?

 

what do u guys think about the advantages or disadvantages of using the so called popular microsoft dotnet framework?

 

gonna prepare something to propose on this monday.

 

thanx for the feedback so far k.

 

cheers,

eddykuan 

eddykuan:

so what do u guys think about the feasibility of developing the dotnet application?

Feasibility - definitely technically feasible. Back in my previous job, I was also facing a mounting task of getting my colleagues to convert over to Sql Server + .NET, and till the very last day when I left, I was still unable to do so. Millions of reasons doesn't justify a switch of language (and in certain cases, platform), afterall, IT systems are built to meet a business need(s); not because the CTO fancies a particular type of platform or language. The cost of crossing over (in terms of language and maybe platform) is simply too much, and there's always the issue of re-training. How does a IT department or company JUSTIFY for such a drastic move which doesn't give any ROI?

chuawenching: i dun quite understand the the difference between the C++ DLL and the C++ Lib and why we need a wrapper for this case?

<WC> Basically you cannot call a C++ library file directly from C#. For more info, check online. Thanks.

what do u guys think about the advantages or disadvantages of using the so called popular microsoft dotnet framework?

<WC> IMHO, check online :) This type of discussion was there for years.

 

ok discuss with my supervisor already, we might implement one of the server in dotnet.

 

will do a full research on the feasibility on implementing the dotnet.

 

so, i wonder whether it is allow if i post out some question over here for dotnet experts to give some suggestion on the feasibility study.

 

thanx and cheers,

eddykuan 

chuawenching:

Basically you cannot call a C++ library file directly from C#. For more info, check online. Thanks.

thanx, will check on it... 

 

chuawenching:

IMHO, check online :) This type of discussion was there for years.

well, maybe i or my company are too slow in the software development world... :P

 

Come over this LOVE event this Saturday, probably you can grab some info from the Ask the Expert's session. :P

thanx for the invitation and recommendation, i try the best to come over.

 

cheers,

eddykuan 

I have always find it a pity that there are still quite a large number of sample coding from Microsoft are not in C# or VB.NET. As such, I have to basically code in VC++ just because the samples are given as such. It makes me wonder if these languages are really that much superior than C# or VB.

I do think that it is possible to rewrite those codes in VB.NET but it would take much longer, I suppose. Yet, time is a luxury I can ill afford with the myraid frameworks and new stuff coming from Microsoft while dealing with everyday work.