Questions on C++ .NET, and .NET in general

[OneSolution]

Hi all,

I'm writing because I haven't been able to find enough information at the
book stores and at the MS web site on some of my questions. Perhaps I'm
asking the wrong questions, but if you could help me out here, I'd really
appreciate it.

One of my clients uses Visual C++ 6.0 extensively. They have started using
C# for many of their coding needs, but the C++ team is deliberating the use
of C++ .NET. However, the questions that come up are:

* What's the big difference between VCPP 6 and VCPP .NET? Is the latter
faster?
* Is it easier to interoperate between VB .NET, C# .NET and VCPP .NET using
the #using pre-processor directive? It seems you still end up having to use
a COM object, and so it's not too much different from the way it used to be.
* If you have code written in VCPP 6 and want to use a library (dll) used in
C#, can you do it?
* Vice-versa - if you have code written in VCPP .NET and want to use a
library (dll) written in VB 6, or VCPP 6, is that possible?
* I read someplace that C# is interpreted. If this is so, then has VB .NET
and VCPP .NET become the same due to the CLR?
* Doesn't that have an impact on performance?
* It seems that the bulk of VCPP .NET is standard ANSI C++. The addition of
managed classes is the unique factor. However, what does this do for
interoperability with older code etc.?
* The Visual Studio .NET 2002 version of the tool doesn't seem to have a
visual designer for C++ programs. Well, not obvious anyway. If I select an
MFC application, then I can design dialog boxes etc. However, this is not
so for managed applications. Any info on whether there will be managed MFC
or something similar coming out in the 2003 version?

I have more questions. Basically, my client wants me to convince them that
it's worth the money to move to .NET. I don't have the evidence to tell
them to do it. Your help is appreciated.

Sincerely,
Santosh Krishnan

 

[Carl Daniel [VC++ MVP]]

Hi all,

I'm writing because I haven't been able to find enough information at
the book stores and at the MS web site on some of my questions.
Perhaps I'm asking the wrong questions, but if you could help me out
here, I'd really appreciate it.

One of my clients uses Visual C++ 6.0 extensively. They have started
using C# for many of their coding needs, but the C++ team is
deliberating the use of C++ .NET. However, the questions that come
up are:

* What's the big difference between VCPP 6 and VCPP .NET? Is the
latter faster?

The compiler is usually slower, the resulting code sometimes faster (due to
optimizer improvements).

* Is it easier to interoperate between VB .NET, C# .NET and VCPP .NET
using the #using pre-processor directive?

In general, I'd say yes, it is. Using #import with COM objects is pretty
easy. Using #using with VB.NET or C#-created classes is quite comparable
in most respects.

It seems you still end up
having to use a COM object, and so it's not too much different from
the way it used to be.

No, you don't have to use a COM object - that's just one of the
interoperation avenues that's open to you.

* If you have code written in VCPP 6 and want to use a library (dll)
used in C#, can you do it?

Yes, you can. You can use P/Invoke from C# to call the VC6 DLL directly
(assuming it exposes a flat C-style API), or you can use Managed C++ (C++
..NET) to create a managed wrapper around the VC6 DLL. If the VC6 DLL
exposes a class-based interface, you'll probably have to recompile the DLL
with VC7{.1} due to incompatibilities at the library level between VC6 and
VC7{.1}

* Vice-versa - if you have code written in VCPP .NET and want to use a
library (dll) written in VB 6, or VCPP 6, is that possible?

Sure. Just expose it as a COM object and consume the COM object in VC6 or
VB6. You can also write COM objects in C# and consume them from VC6 or VB6.

* I read someplace that C# is interpreted. If this is so, then has
VB .NET and VCPP .NET become the same due to the CLR?

C# is not interpreted - no .NET languages are. The C# compiler produces CIL
which is JIT-compiled to native machine language when the program is loaded.

* Doesn't that have an impact on performance?

There's a startup cost associated with the JIT. In many cases, C#/VB.NET
code rivals the performance of native code. In a few cases, .NET code is
faster, in a few more cases, native code is faster. It's rare for the speed
difference to be more than 20% or so in either direction.

* It seems that the bulk of VCPP .NET is standard ANSI C++. The
addition of managed classes is the unique factor. However, what does
this do for interoperability with older code etc.?

It neither hinders nor help interoperability with older code at the language
level. It does allow you to write managed wrappers to expose older native
code to other .NET clients.

* The Visual Studio .NET 2002 version of the tool doesn't seem to
have a visual designer for C++ programs. Well, not obvious anyway.
If I select an MFC application, then I can design dialog boxes etc.
However, this is not so for managed applications. Any info on
whether there will be managed MFC or something similar coming out in
the 2003 version?

Visual Studio .NET 2003 has the windows forms designer for C++. It's pretty
widely agreed that Windows forms is not ready to rival MFC for development
of complex GUIs, but for simple things it's quite a lot easier.

I have more questions. Basically, my client wants me to convince
them that it's worth the money to move to .NET. I don't have the
evidence to tell them to do it. Your help is appreciated.

Keep the questions coming. There's lots of people here who can help to
answer them.

-cd

 

[OneSolution]

Thanks a lot! I shall do that. Some of these answers are what my client
wants to hear.

Their argument is that if MFC isn't any different in C++ 7.1 than it is in
C++ 6, then why should they upgrade.

Then the other thing is, (and I am assuming here) that C# and VB .NET
generates managed code by default. I'm not so sure that's true, but I
haven't heard to the contrary. So if they do generate managed code(???)
then should anything special have to be done to import them into C++ 7.1?
So then

My client experimented and told me that they had to make a TLD wrapper
around their C# library to use it. Now I don't have details on how their C#
code has been written, but I told them that they could use a COM object to
access their dll, but they also could do without it. They vehemently argued
that you can't simply use a dll from C# without some sort of COM wrapper.
At this point, I'm a bit lost on what they're doing, as I'm not a big CPP
programmer (I do Java ...).

Well, thanks again!

Santosh

 

[Carl Daniel [VC++ MVP]]

Thanks a lot! I shall do that. Some of these answers are what my
client wants to hear.

Their argument is that if MFC isn't any different in C++ 7.1 than it
is in C++ 6, then why should they upgrade.

MFC in VC7.1 has a few improvements over VC6, most notably better
integration with ATL. I'm not an MFC person, so I can't comment much
beyond that. You might want to post to microsoft.public.vc.mfc and ask
about the differences between MFC 4.2 (that's included with VC6) and MFC 7
(that's included with VC.NET).

Then the other thing is, (and I am assuming here) that C# and VB .NET
generates managed code by default. I'm not so sure that's true, but I
haven't heard to the contrary. So if they do generate managed
code(???) then should anything special have to be done to import them
into C++ 7.1? So then

C# and VB.NET generate managed code exclusively. The only .NET language
that can produce native code is C++. You're correct - you can directly use
any C# or VB.NET generated class from VC7{.1} without modification or
wrappering.

My client experimented and told me that they had to make a TLD wrapper
around their C# library to use it.

In order to use a C# library in VC6, you'll have to expose it as a COM
object. That doesn't necessarily involve any wrappering, as a .NET class
can be designed to be both .NET and COM friendly at the same time.

Now I don't have details on how
their C# code has been written, but I told them that they could use a
COM object to access their dll, but they also could do without it.
They vehemently argued that you can't simply use a dll from C#
without some sort of COM wrapper.

That's just not true in general. The place it is true is if the DLL exposes
a class-based interface. In that case, you must make a wrapper to expose
native C++ classes to .NET. The wrapper doesn't have to be COM though - it
could just as well be Managed C++.

At this point, I'm a bit lost on
what they're doing, as I'm not a big CPP programmer (I do Java ...).

Well, thanks again!

You're welcome.

-cd

 

[OneSolution]

Any good online VC++ 7.1 reference web sites?

Thanks,
Santosh

 

[OneSolution]

Hi Carl,

Thanks a lot. For question 3, basically, it's a standard operation where a
DLL is being used by an EXE. However, there is one class within the EXE
that the DLL needs to use, but due to various engineering problems, can't be
extracted from that exe. So is it possible for the DLL to call the class
within that EXE?

Thanks,
Santosh

Hi Carl,

Thanks for your answers. I have some more questions.

[cd] Please post questions on the newsgroups so that others may benefit from
the answers as well.

1. My client has a C++ 6.0 exe file that is the core of their product. It's
an MFC product. They want to know if it's possible to build a windows forms
based front end and then have that use the functionality within the exe
without having to start the execution at the exe. Basically, my
understanding is that they'd like to use the exe like you would a DLL except
that it would have a main function in it. I'm not so sure you can do this,
but I thought I'd ask.

[cd] No, this is not possible (unless, for example, the MFC EXE already
exposes it's functionality as an out of process COM object). It's not
possible (without a LOT of work) to load an EXE like a DLL and call
functions inside it. This despite the fact that EXE's can in fact export
functions, just like DLLs can. The best solution for their existing app
would be to refactor it into an EXE and one or more DLLs (that this EXE
uses), and call those core DLLs from the WinForms app as well.

2. If the icon associated with an exe has to be changed out often, is it
possible in .NET to do so without having to rebuild the exe every single
time with a new icon in it?

[cd] The app only has to be re-linked to change the icon, and that's no
different in .NET, as far as I know (I'm neither an MFC guy nor a WinForms
guy, so I'm guessing to a point). If only the icon is being changed, it's
fairly straightforward to construct a program that can edit the resources of
an EXE and replace one icon with another, thus avoiding the build system
entirely.

3. If an exe calls a DLL that has a lot of functionality in it, but there is
one class in the exe that the DLL needs, can the DLL access the class in
..NET?

[cd] At first read, I thought what you were asking about here is basically
the same as question #1, but on re-reading I'm not sure. Could you clarify
the scenario you're asking about?

Thanks a bunch!
Santosh