Thank you very much for your response.
Many of the systems that require performance -like image processing, voice
recognition, military software- are developed in C++. In the course of the
time, can C# find a considerable a good place in these areas?
Within the projects that are in C#, using the C++ codes is possible.
Therefore, can C# be used in Performance-Required areas?
I create imaging software, and I try to create the user interface part and
the stuff that is less performance critical in C# because I can create that
part much faster.
But a huge part of my code base is unmanaged C++ using MFC. And I simply do
not have the time to port it to C# or managed C++ at this moment, so I have
created a mixed C++ assembly that has both managed as unmanaged code acting
as wrappers.
The nice thing about .NET is that I can create components in C#, managed
C++, VB.NET... and freely mix them with each other without any problems.
Just make sure that you avoid case sensitivity in de class naming to make
sure that it can still be used in VB.NET. But you have a program that checks
compatibility called FxCop that analyzes your code assembly and explains
what you might to change things in a very friendly manner.
Now the problem is that you either create a C# assembly or a C++ managed
assembly. You cannot compile C++ code in a C# project. So you end up with
multiple assemblies (dll's), which at first sounds scary for the
installation procedure, but a .NET program is best installed using a setup
so that does not pose any problem. The setup can automatically configure the
computer for enough user rights to run that program across a network and
so... So no more complicated installation and user righst.
One thing I had problems with in the beginning was this MFC thing. I
discovered that I need to compile with MFC in a DLL, and this gave me
problems because I used the assemblies in a subfolder which is a nice system
to avoid dll clashes if one assembly needs v1.2 of a dll and the other
assemblie used in your same program uses that same assebly name but with a
different vesrion v1.1. I discoverd that the subfolder thing was perfect for
none-MFC dll's. The MFC dll's should reside in the same folder of your dll
and executable.
You will lose some speed if you move from managd to unmanaged code and back.
So it is best to concentrate the code into managed or managed code, but try
to avoid the transition as much as possible. But it works greate.
I faced one small problem. one of the projects I created is a dll plugin for
a conventional exe program. The dll is a mixed manged/unmanaged dll that
have the user interface as a managed part. But it turned out that the .NET
framework did not find the correct assemblies even though they were located
in the same folder of the main dll. The reason was because the executable
was located in another folder, the plugin in yet another folder. The .NET
framework tried to locate the dll's in the .EXE folder instead of the plugin
..DLL folder. Since creating a setup is not desired that installs plug-ins in
the program folder of the exe, suppose you have 2 plugins with the same
name? I found a sollution in installing the assemblies into the GAC. I don't
like that but it is the best solution so far I have come up with that is
reliable. Setting the current directory didn't solve the problem.
So I hope that you have now an overview of what is possible.
