Native win32 apps still require .NET runtime?

[Dave]

I understand that VS.NET is supposed to compile native Win32 apps that
do not require the .Net runtime. If that's the case then there is
something else from the VS200x package that is required.

MSVCR80.DLL and MSVCR80D.DLL are present and accounted for in
Windows\System32. This is something else.

Message says that the application configuration is incorrect. I just
compiled a simple "Hello.cpp" app that exhibits the same behavior so
this should be easy to duplicate.

What's missing?

 

[Guest]

Native Win32 Apps do not require the .NET Framework. If you're using MFC, did
you set the project to use MFC in a static library? Maybe you should post the
exact error message.

Cheers,
Mark

 

[Dave]

Native Win32 Apps do not require the .NET Framework. If you're using MFC, did
you set the project to use MFC in a static library? Maybe you should post the
exact error message.

The error message is: "This application has failed to start because
the application configuration is incorrect. Reinstalling the
application may fix this problem."

I've been able to reproduce this on a couple machines now, and I've
confirmed that others have seen the same error message (below) in
similar cases. Still no real clues to the cause.

No MFC. As mentioned, I've seen this with a plain console 'hello'
program. MSVCR80 dlls are in Windows\System32.

This does not occur on systems where VS2005 is installed.
I don't remember seeing this with VS2003.

If the error message is to be taken literally, then there's something
that needs to be configured aside from simple copying of DLLs. ????
I didn't think that was the case with straight unmanaged apps.

 

[adebaene]

The error message is: "This application has failed to start because
the application configuration is incorrect. Reinstalling the
application may fix this problem."

I've been able to reproduce this on a couple machines now, and I've
confirmed that others have seen the same error message (below) in
similar cases. Still no real clues to the cause.

No MFC. As mentioned, I've seen this with a plain console 'hello'
program. MSVCR80 dlls are in Windows\System32.

This does not occur on systems where VS2005 is installed.
I don't remember seeing this with VS2003.

If the error message is to be taken literally, then there's something
that needs to be configured aside from simple copying of DLLs. ????
I didn't think that was the case with straight unmanaged apps.

First use dependency walker on the target machine to check wether any
DLL you may not be aware of is missing.

Arnaud
MVP - VC

 

[Dave]

First use dependency walker on the target machine to check wether any
DLL you may not be aware of is missing.

That's one of the first things that I tried, Arnaud. Especially in
the case of the "Hello World" release build, that was not complex--it
just uses MSVCR80.dll (and of course Kernel32 and NTDLL).

In other words, printf("Hello"); compiled w VS2005 will not run on a
machine unless VS2005 has been installed.

Again, the error message is: "This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem."

Compiling the same code under VS2003 exhibits no problems when running
on a plain-vanilla test machine with no compilers installed..

Any other ideas?

 

[Willy Denoyette [MVP]]

That's one of the first things that I tried, Arnaud. Especially in
the case of the "Hello World" release build, that was not complex--it
just uses MSVCR80.dll (and of course Kernel32 and NTDLL).

In other words, printf("Hello"); compiled w VS2005 will not run on a
machine unless VS2005 has been installed.

Again, the error message is: "This application has failed to start
because the application configuration is incorrect. Reinstalling the
application may fix this problem."

Compiling the same code under VS2003 exhibits no problems when running
on a plain-vanilla test machine with no compilers installed..

Any other ideas?

You'll have to add the .manifest file to your distributon or you need to
embed the manifest to the .exe file (this is normaly done when you build
from within the IDE).
Note that on XP and higher, MSVCR80.dll (and other C++ runtime dll's) should
be installed in the SxS folder (Side by Side assembly folder).
Please search MSDN for "manifest" and "side by side assemby" for more
details on shared runtime assemblies.

Willy.

 

[Dave]

You'll have to add the .manifest file to your distributon or you need to
embed the manifest to the .exe file (this is normaly done when you build
from within the IDE).
Note that on XP and higher, MSVCR80.dll (and other C++ runtime dll's) should
be installed in the SxS folder (Side by Side assembly folder).
Please search MSDN for "manifest" and "side by side assemby" for more
details on shared runtime assemblies.

Thanks for the followup, Willie. I had hoped that this was a simple
global config option, but it appears not.

If I'm understanding this, the "Hello World 2005" tutorial just grew
from one page to about 4 chapters (versioning schemes, manifests,
deployment strategies, etc).

This looks like a horrible blunder by the Microsoft team. MS needs to
devise an intelligent tool that will make deployment easy. Especially
since many writing Win32 code under VS2005 are just trying to port
their old apps. Given the likelihood that users will encounter this
problem, I'd also think that MS's error messages could be better.

I've looked through the code at Nikola Dudar's blog:
http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx
Tried the recommendation, but just traded in for a different set of
error messages.

Does anyone have a coherent list of changes (to manifests, DLLs,
whatever) that will make VS2005 apps work?

 

[Michael Viking]

If I'm understanding this, the "Hello World 2005" tutorial just grew
from one page to about 4 chapters (versioning schemes, manifests,
deployment strategies, etc).

You must be doing something wrong. The whole idea of .NET, etc., is that
everything is easy to deploy and stuff just "works". DLL hell is now a
thing of the past.

This looks like a horrible blunder by the Microsoft team. MS needs to
devise an intelligent tool that will make deployment easy. Especially
since many writing Win32 code under VS2005 are just trying to port
their old apps. Given the likelihood that users will encounter this
problem, I'd also think that MS's error messages could be better.

It's actually brilliant. You just have to take a different point of view of
Microsoft's strategy and what they're trying to accomplish. Time will show
this.

-Michael Viking.

 

[Dave]

You must be doing something wrong.

Ha! I'm wondering if I misspelled "Hello" or if it was "World"

The whole idea of .NET, etc., is that everything is easy to deploy and
stuff just "works". DLL hell is now a thing of the past.

It Just Works (IJW) is a nice catch-phrase, but it this case, IJDW.

It occurs to me that you may not have actually tried this. Build an
unmanaged C++ "Hello World" app with VS2005, transfer it to a
machine that doesn't have VS2005. Then see what you have to
do to get it to run.

Think about it...if the DLLs are named the same (MSVC80x for both
beta and release of VS2005) then how is the EXE file going to find
the right one? It has to point at the correct DLL via manifest. When
you transfer your program to the other machine, where's are the
correct DLLs?

I'd still love to hear from anyone who has a coherent method for
solving this.

 

[David Wilkinson]

Dave wrote:

[SNIP]

Think about it...if the DLLs are named the same (MSVC80x for both
beta and release of VS2005) then how is the EXE file going to find
the right one? It has to point at the correct DLL via manifest. When
you transfer your program to the other machine, where's are the
correct DLLs?

I'd still love to hear from anyone who has a coherent method for
solving this.

Dave:

I do. It's called static linking.

David Wilkinson

 

[Michael Viking]

Dave, see below:

Ha! I'm wondering if I misspelled "Hello" or if it was "World"

It Just Works (IJW) is a nice catch-phrase, but it this case, IJDW.

It occurs to me that you may not have actually tried this. Build an
unmanaged C++ "Hello World" app with VS2005, transfer it to a
machine that doesn't have VS2005. Then see what you have to
do to get it to run.

<SNIP>

I've been being sarcastic. You're right I've never tried it. Those are
just phrases I remember the billion dollar marketing machine trying to force
feed me. It only took us about 2 weeks of playing with the first .NET beta
years ago to stick with VC 6 for our needs. Still using it, still not
having any problems, still haven't wasted any time learning obsolete syntax.

-Michael Viking

 

[Dave]

Dave, see below:

I've been being sarcastic. You're right I've never tried it. Those are
just phrases I remember the billion dollar marketing machine trying to force
feed me.

Ah, sorry. I didn't expect that in a dotnet group. I love the new
development environment and see logic in trying to maintain DLL
versioning, etc. But not if it means that apps won't work at all.

In searching for info, I've even seen mention of a commercial app that
has run into a snag with a distributed program due to this! "DLL Hell" is
back with a vengeance. Copying folder trees and manifests from WinSxS
does not fix it. Nor does the recommended fix I've seen on MS sites (copy
DLLs and manifest into local folder and rename the manifest).

You are correct that a lot of the MS market-speak gets repeated without
being questioned. I've seen otherwise knowledgable people in this group
say that unmanaged apps can be generated in VS2005 and will run without a
hitch. Inquiries about keeping VC6 loaded are often answered by "No
need."

The problem seems easy to duplicate. I've talked to others who have
encountered it and dropped back to VC6 as a result. After seeing this
turn up on several machines, I have to conclude that the experts simply
haven't tried it and are, as you said, repeating MS market-speak. I wish
it weren't so.

 

[Dave]

Dave wrote:

[SNIP]

Think about it...if the DLLs are named the same (MSVC80x for both
beta and release of VS2005) then how is the EXE file going to find
the right one? It has to point at the correct DLL via manifest. When
you transfer your program to the other machine, where's are the
correct DLLs?

I'd still love to hear from anyone who has a coherent method for
solving this.

Dave:

I do. It's called static linking.

David Wilkinson

You're right, that works. HelloWorld is 400K+ but it runs.

I'm very curious now, has no one tried running unmanaged apps on
non-development machines? That seems a stretch. But I've heard about
this from several knowledgable programmers now.

Even copying the WinSxS folders and manifests does not fix the dynamic
link problem, so bottom line: VS2005 does NOT generate reliable standalone
native apps.

If anyone knows how to fix the manifest, please speak up. The MS fix at
http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx does not
work.

 

[David Wilkinson]

Dave wrote:

[SNIP]

Think about it...if the DLLs are named the same (MSVC80x for both
beta and release of VS2005) then how is the EXE file going to find
the right one? It has to point at the correct DLL via manifest. When
you transfer your program to the other machine, where's are the
correct DLLs?

I'd still love to hear from anyone who has a coherent method for
solving this.

Dave:

I do. It's called static linking.

David Wilkinson

You're right, that works. HelloWorld is 400K+ but it runs.

Yes, it is. But my modest size MFC app weighs in at only 870KB and is
copy-install to all Win32 platforms. There is no way you can get the
total deployment down to this size if you have to ship MFC and CRT DLL's

I really do not understand why one would not use static linking unless
you have an architecture (MFC extension DLL's or mixed
managed/unmanaged) that requires it.

In addition, the MSLU technique for running "Unicode" apps on Win9x/Me
requires static linking, unless you want to rebuild the MFC and CRT DLL's.

David Wilkinson

 

[Dave]

I really do not understand why one would not use static linking unless
you have an architecture (MFC extension DLL's or mixed
managed/unmanaged) that requires it.

The latter is not ringing a bell at the moment, David. Why do mixed
managed/unmanaged apps require dynamic DLL linkage?

 

[David Wilkinson]

On Thu, 08 Dec 2005 07:02:51 -0500, David Wilkinson



The latter is not ringing a bell at the moment, David. Why do mixed
managed/unmanaged apps require dynamic DLL linkage?

Dave:

I read it on the newsgroups. And I must say it was the death-knell for
any thought I had of compiling my MFC app with CLR.

I would like to understand why mixed apps must link dynamically. Anyone?

Back to the thread topic, I must say I am very shocked by what you are
telling us here. Is deployment of dynamic linked applications really so
difficult?

David Wilkinson

 

[David Ching]

It occurs to me that you may not have actually tried this. Build an
unmanaged C++ "Hello World" app with VS2005, transfer it to a
machine that doesn't have VS2005. Then see what you have to
do to get it to run.

Dave, I tried this for you. I used VS2005 to create a C++ Console
Application. I filled in:

int _tmain(int argc, _TCHAR* argv[])
{
printf ("Hello world\n");
return 0;
}

I left all the default settings alone. I built the RELEASE configuration.
The result was HelloWorld.exe that was 5,632 bytes.

I copied that into a VMWARE Win2K installation I had previously configured.
It did not have VS2005 installed in it. I ran the program and got:

"The dynamic link library MSVCR80.DLL could not be found in the specified
path..."

I copied MSVCR80.DLL from my host PC (which has VS2005 installed) from

c:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd

to the virtual machine (into the same folder as HelloWorld.exe). This file
was 626,688 bytes. There was also another file named MSVCR80.DLL in the
folder C:\WINDOWS\WinSxS\amd64_Microsoft.VC80\..., but since I don't have an
amd64, I did not use this one.

I then ran HelloWorld.exe on the virtual machine. It ran fine. HTH, I
really recommend you statically link the RTL instead... but I did not find a
setting in the IDE to choose this.

David
http://www.dcsoft.com

 

[Dave]

I tried this for you. I used VS2005 to create a C++ Console
Application. I filled in:

int _tmain(int argc, _TCHAR* argv[])
{
printf ("Hello world\n");
return 0;
}

I left all the default settings alone. I built the RELEASE configuration.
The result was HelloWorld.exe that was 5,632 bytes.

I copied that into a VMWARE Win2K installation I had previously configured.
It did not have VS2005 installed in it. I ran the program and got:

"The dynamic link library MSVCR80.DLL could not be found in the specified
path..."

I copied MSVCR80.DLL from my host PC (which has VS2005 installed) from

c:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd

to the virtual machine (into the same folder as HelloWorld.exe). This file
was 626,688 bytes. There was also another file named MSVCR80.DLL in the
folder C:\WINDOWS\WinSxS\amd64_Microsoft.VC80\..., but since I don't have an
amd64, I did not use this one.

I then ran HelloWorld.exe on the virtual machine. It ran fine. HTH, I
really recommend you statically link the RTL instead... but I did not find a
setting in the IDE to choose this.

David
http://www.dcsoft.com

Thanks so much for testing it! I was afraid that it would work for
some... I guess that means it won't be fixed. I'm out of clues.

Re static link: You'd think that might be in the linker options page,
but it's a compile phase option:
Project properties -> C/C++ -> Code Gen -> Runtime Lib
You'd change the /MD option to /MT for release.
/MDd to /MTd for debug build.

Since that fixes the DLL error, it would seem that the problem occurs
due to incorrect generation or interpretation of the manifest file. There
are a few phases though, so I'm not sure how to nail it down.

Thanks again for testing this, David.

 

[David Ching]

Re static link: You'd think that might be in the linker options page,
but it's a compile phase option:
Project properties -> C/C++ -> Code Gen -> Runtime Lib
You'd change the /MD option to /MT for release.
/MDd to /MTd for debug build.

Thanks, I knew it was something to do with /M<mumble> It's confusing
because on the General page, if you have an ATL or MFC project, there is a
combobox that lets you choose whether it's statically linked or dynamically
linked. I don't know why it doesn't appear for console apps, since they too
require the C RTL if not a framework lib.

Since that fixes the DLL error, it would seem that the problem occurs
due to incorrect generation or interpretation of the manifest file.

I don't have much experience with VC2005 yet, but I did run into a problem
where I had manually added a manifest to a VC6 project, and it caused a
build problem with VC2005. I manually edited the .rc file to remove my
manifest, and it built fine. Perhaps you could do the same thing. Maybe
your old manifest isn't compatible with VC2005 or something.

If all else fails, I would use VC2005 AppWizard to generate a new project
and then add all your source files. Maybe your project wasn't converted
properly.

Cheers,
David

 

[Dave]

I read it on the newsgroups. And I must say it was the death-knell for
any thought I had of compiling my MFC app with CLR.

I've written lots of MFC apps but haven't been tempted to recompile
those with CLR. They will probably stay native (they'll still compile
OK with VC6 or 7). I'm not sure how many people are using MFC with
CLR, so maybe MS is just not getting enough feedback to fix problems.

On the other hand, I think some of the Microsoft techs like to close
out trouble tickets whether the problems are fixed or not. There...
all the bugs went away.

I would like to understand why mixed apps must link dynamically. Anyone?

Me too. I'm thinking that when the 2005 .NET Framework is installed
it may fix the bug I've seen, so I don't want to do that. Best find
out what it is now.

But if this shows up indirectly in mixed .NET / Win32 apps, then some
people are really stranded.

Back to the thread topic, I must say I am very shocked by what you are
telling us here. Is deployment of dynamic linked applications really so
difficult?

All VS2005 apps so far run fine from within VS2005, so maybe that's
the solution: Ship VS2005 with every app, with instructions on how to
run it in the debugger. <g>

I was originally skeptical someone told me about the DLL problem. I
told him that he must be doing something wrong (oops). After I was
able to get the bug to surface on a test machine, it now seems easily
reproducible.

I think MS has made DLL versioning way more difficult than it needed
to be. It seems unlikely that intermediate-level users are going to
wrap their minds around stuff that's thrown some of the experts here
(not speaking for myself). Versioned DLLs...great. But you need a
new DLL, complex folder names and other baggage. What did that save?
I have to question why they didn't just issue DLLs with a new name,
like VCRWhatever_50727.DLL. The app reports that it needs it and the
user does a search and downloads it. Forget about that happening now.

All this is for Win32 'Hello World.' Mixed mode has me concerned.

Anyway, policy files are the redeeming feature of the new garbled
mess. If they work, they would handle DLLs with new names and save
downloads if version changes are minor (as is apparently the current
case...VS is creating manifests with old DLL names).

I'm still trying to figure out why this got so convoluted. There is
apparently no way to trace back problems. It has cost me hours. I
know developers who have given up and gone back to earlier compilers.
VS2005 has some compelling features but it looks like beta 3 so far.
I'm not sure how they can fix this.