VS6 code compiled w VS2005 needs .NET framework?

[-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?

[Carl Daniel [VC++ MVP]]

"-DG-" <-D**@nospam.com> wrote in message
news:6s********************************@4ax.com...

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?

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

[-DG-]

On Mon, 17 Oct 2005 15:44:13 -0700, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:

"-DG-" <-D**@nospam.com> wrote in message

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?

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.

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?

[William DePalo [MVP VC++]]

"-DG-" <-D**@nospam.com> wrote in message
news:fu********************************@4ax.com...

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

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

[Carl Daniel [VC++ MVP]]

-DG- wrote:

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?

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

[-DG-]

On Wed, 19 Oct 2005 06:51:31 -0700, "Carl Daniel [VC++ MVP]"

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

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.

[William DePalo [MVP VC++]]

"-DG-" <-D**@nospam.com> wrote in message
news:7d********************************@4ax.com...

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.

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