VS6 code compiled w VS2005 needs .NET framework?

  • Thread starter Thread starter -DG-
  • Start date Start date
D

-DG-

I'm told that when an VC++ 6 project is copied and compiled with the
VS2005 compiler, that the runtime requires the .NET framework. I
don't have any machines handy that *don't* have the framework
installed so I can't confirm this.

Any idea why that would be or how to compile so .NET is not required?
 
-DG- said:
I'm told that when an VC++ 6 project is copied and compiled with the
VS2005 compiler, that the runtime requires the .NET framework. I
don't have any machines handy that *don't* have the framework
installed so I can't confirm this.

Any idea why that would be or how to compile so .NET is not required?
Click to expand...

Whoever told you that was sorely misinformed. Code compiled with VC++ 2005
(or 2003 or 2002) only requires the .NET framework if you choose to make it
require the .NET framework.

-cd
 
Whoever told you that was sorely misinformed. Code compiled with VC++ 2005
(or 2003 or 2002) only requires the .NET framework if you choose to make it
require the .NET framework.
Click to expand...

Is the compiler /clr flag the sole thing that determines whether the
..NET framework is accessed?

The only other thing that I can think of is that maybe there's a new
equivalent to VC++6's runtime DLLs. Or does VS2005 in this case
compile for the older DLLs?
 
-DG- said:
Is the compiler /clr flag the sole thing that determines whether the
.NET framework is accessed?
Click to expand...

In practical terms that's true. If one's goal is to target the .Net platform
one has to use a language that compiles to MSIL. The /clr option does that.

But note that a sophisticated application can load and start (some would say
host) the .Net Common Language Runtime. It's not often necessary, but it is
done in unmanaged code. It's not the kind of thing that you do by accident
as would be the case with an option chosen in error.

Regards,
Will
 
-DG- said:
The only other thing that I can think of is that maybe there's a new
equivalent to VC++6's runtime DLLs. Or does VS2005 in this case
compile for the older DLLs?
Click to expand...

In addition to Will's response...

Like VC7 and VC7.1 before it, VC8 includes new runtime DLLs that must be
distributed with your application - tageting the older DLLs that are shipped
with the operating system is not supported (but can be done if you work at
it hard enough, and disable enough VC8 features).

-cd
 
Like VC7 and VC7.1 before it, VC8 includes new runtime DLLs that must be
distributed with your application -
Click to expand...

I'm working blind, as all my machines have the framework installed.
The failure was reported by someone who doesn't have the framework,
and I bet he misinterpreted the error message. It was probably
complaining about DLLs rather then the .NET framework.

I don't suppose there is an easy way to turn off framework support to
test this?

Also, does anyone happen to have a list of DLLs that (may) need to be
loaded by native apps compiled with VS2005? I remember going through
this with every previous rev of VC++ and I usually miss at least one.
 
-DG- said:
Also, does anyone happen to have a list of DLLs that (may) need to be
loaded by native apps compiled with VS2005? I remember going through
this with every previous rev of VC++ and I usually miss at least one.
Click to expand...

I don't but you can get information about the DLLs to which your application
is implicitly linked with the command

dumpbin /imports YourExeNameGoesHere.exe

of with Depends if you have that tool.

Regards,
Will
 
Back
Top