manifest problems with Visual Studio 2005 and WindowsXP

Question

Am having much issues with the Visual Studio 2005 manifest thing.  Running on WinXP/SP3.
All of the issues have to do with running only on the development machine - have not even tried to distribute to another machine yet.

Scenario.  We have a legacy program that is fairly large and we have compiled it in NON-debug with standard makefile.  We now need to compile and build on Visual Studio 2005, which we did successfully.
A manifest file is created for one of the dlls.
it looks like this:
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.5060
8.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>
 
I then run command "mt -manifest thismanifest -outputresource:mydll.dll;1" in order to embed the manifest into the dll.
 
Any programs that use ths dll must also be "fixed up" with the mt command before they will run.
All works well as long as I "fix up" similarly to above with the mt.exe all of the program that require this dll.
 
Now, I have an application which uses this dll but want to compile it with debug turned on.
BTW, if I compile it without debug (Release), it works after I embed the manifest into it.
But if I compile it with debug, I absolutely cannot get tis app to load.  It has a manifest that looks like this (why the funny characters in the beginning?):
 
´╗┐<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0
.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemb
lyIdentity>
    </dependentAssembly>
  </dependency>
</assembly>
 

The app gets the popups R6034 and then a 0xc0000142.  Fails to load.
I surmise the app needs the non-debug manifest and also the debug manifest.  I tried merging manifests and then the program becomes "not a program" - gets invalid message when try to run it.
 
Tried to just embed the non-debug manifest into it and still get the popups.
I have spent days on this.  I have copied the msvcr80.dll, msvcr80d.dll, etc and their manifest files into the app directory and made it first in th epath.

Set the environment variable WIN32_REDIST_DIR to point to the directory.  Saw this on the net somewhere.

The files I copied are below:

07/01/2009  05:08 PM               522 Microsoft.VC80.CRT.manifest
07/01/2009  05:08 PM               529 Microsoft.VC80.DebugCRT.manifest
07/01/2009  03:36 PM           479,232 msvcm80.dll
07/01/2009  03:36 PM           548,864 msvcp80.dll
07/01/2009  03:36 PM           626,688 msvcr80.dll
07/01/2009  03:32 PM         1,171,456 msvcr80d.dll
 
Tried all I can think of to get this program to work.  Interestingly, compiling it with Release makes it work.
Withouth the Microsoft manifest files in the directory and also without that environment variable set.
  
Nothing works.  This is a nightmare.
Anyone know the magic for making this work?  I have a couple very unhappy customers who require this 2005 compiled server.
 
Thanks much,
 
 
Jim

Answer 1

Hmya, such is the price of using makefiles instead of the IDE build system.  One mistake you made is embedding the manifest into the DLL as resource ID #1, it must be 2.

The manifest must also match the CRT version you've got on your machine.  You didn't mention whether or not you've got SP1 installed.  Best thing to do is to create a simple IDE project and have it generate the manifest.  File + New Project, select Win32, Win32 Console Application.  No need to enter code, Build + Build.  Look in the project's Debug directory for the .manifest file.

Also make sure you deploy the CRT libraries on the target machine.

---

Hans Passant.

Answer 2

Thank you, Thank you, Thank you, Thank you, Thank you, Thank you!!!!
Embedding the manifest into the dll as #2 did it.  All else seemed OK.

This legacy server is several hundred c modules and about 40 separate makefiles with approx 9 executables.
Originated in OS/2, then AIX, HP, then Linux, then NT, XP etc.

Prior to this, it made no sense using the IDE to build it and this is a one-off (or two-off) build for a couple customers.

This has been a frustrating week for me. 

I thank you very much for your very quick and accurate reply.

Pass this to your bossman.......

Jim

Answer 3

Not to be totally satisfied that this just now seems to work because I gave "2" for on the mt command for my dll.

I read the entire help for mt.exe and it merely says the word resource_id with no explanation of it.  So then I searched on http://msdn.microsoft.com/en-us/library/aa376617(VS.85).aspx and see a chart for the resource_id which explains it.
The way I read it however, is that i should use #2 for my dll and also #2 for my exe.

What I did was use #2 for my dll and #1 for my exe; which, according to the chart, should not have worked (I think).
The exe was buit via IDE and I saw no place to specify #1 or #2 so just took the default. 
A mt.exe extract on #1 from the exe gave me the debug msvcr80d.dll manifest - so I assume the manifest was #1. 
I did specify #2 for the dll via the mt.exe program.

Some examples in the msdn would be really useful for us command line junkies.

BTW, it is really impossible to try to use this forum using other browsers (Mozilla, Opera).  Running Linux on my laptop gives me no access to NO Internet Explorer.  I actually have to Remote Desktop to a machine at work and cut/paste the reply.

Intentional??

I know, this is a Microsoft forum so hence Internet Explorer only.

Thanks,

Jim

Answer 4

No, the manifest in the .exe requires resource ID #1.  All of this is unusually poorly documented, it is buried in here .  The only complete docs I know for mt.exe is the one you get with /?  Ought to please a cmdline junkie.

Use FireFox.

---

Hans Passant.

Answer 5

Resurrecting this thread.

We are still having issues with our customer using our DLL.  Asked him to verify he is using our latest DLL changed as per your suggestion to use #2 in the DLL.

Funny think, however.  In trying to duplicate his issue, I have built, using 2005 IDE, a program in Debug (not Release) mode.
It does NOT call for MSVCR80D.DLL (via depends) and has an "empty" manifest as below.  When I run it in the debugger, I see symbols, etc as I should.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
</assembly>

Just when I think I was beginning to get the hang of it.  Apparently I'm not even close.

What gives with this.... please...

Thanks,

Jim

Answer 6

OK.  I gotta rant on this manifest and MSVCR80/MSVCR80D dll thing.
We've been trying to get a customer in China to use one of our DLLs built with Visual Studio 2005 for about 3 weeks now. 
My previous posts give the reasons we don't build our dll with the IDE.  It's just huge.
They have built their programs (two of them) using the IDE and so they have manifests in them as noted above.
I have sent them the original command line version - that didn't work of course.  Then I sent them a dll that had the manifest - but of course, in the wrong slot(??).  I.e. I did "mt -inputresource:manifest -out:mydll.dll;#1" - Did not realize it should be #2 instead of #1 at the time.  Most of examples showed #1. 
So...nobugz kindly set straight on that and I injected the manifest into mydll.dll at #2.  Manifest for msvcr80.dll.

So we have a customer using a Win32 gui app compiled with debug and a manifest calling for msvcr80d.dll trying to use mydll.dll which calls for msvcr80.dll.
He says it won't load.  I have tried everything I know of.  Placed msvcr80/msvcr80d in different places (like mydll direcotry, \windows\system32), copied the directory from /ms installdirecotry/Microsoft.VC80.CRT to the same directory containing mydll.dll

The customers are frustrated, I am frustrated.  This is ridiculously complex.  OK. so I see why they tried to do this to make sure the correct dll is loaded, but at least, cannot the loader put out a decent message and let me know why it doesn't want to load the program.  That stupid popup is worthless and just points you mostly to some of the other posts on these forums complaining about the same thing I am complaining about.

We both are testing on a development system with VS2005 installed and we both have the /windows/winsxs directory with all the stuff there.

Just a simple English (even German, French) message that tells me why it won't load.  Not that stupid 8 digit hex code that is not even documented properly -just says basically that something is wrong.

A program knows exactly why it can't load, SPIT IT OUT..

Sorry for the rant and rave. I am upset, the Chinese customer is upset, my boss is upset, the beancounters are upset.

Thanks,

Jimb

Answer 7

It does get spit out, into the Windows event log.  Vista has Sxstrace.exe for additional diagnostics.

---

Hans Passant.

Answer 8

"Application popup: pgm.exe - Unable to Locate Component: This application has failed to start because MSVCR80.DLL was not found. Reinstalling the application may fix this problem."

This is the Event log I got when I first got going and didn't have a manifest in my dll at all.
Sorry, but this is not even close to a description of the problem

I am sure that all of this is just an excuse for not reading the manual or the reams of MSDN online stuff, but this type of log entry is useless and could be a lot better.
Like... the missing MSVCR80.DLL was not missing from the application manifest because it required MSVCR80D.DLL.  It was my dll that had no manifest and therefore no reference to it's required dll.

I think this whole thing is a big nightmare for people trying to provide product to users.

I'll leave it alone now and just hope we can somehow get our customer going eventually. 
Ah-ha  I just got it.  This is ploy by Microsoft to get everyone to buy a support contract........

Anyway, thanks for all your help.

Thanks,

Jim

Answer 9

Jimb,

 

I haven't seen your previous posts, but is your DLL in the same folder as the .exe that uses it?  If not, try putting your DLL in the same folder as the .exe, and make sure the Microsoft.VC80.CRT folder (which you say you copy to the same folder as your DLL) is also in that same folder.

 

-- David

 

"j1mw3b" wrote in message news:9334fccd-8999-4ef f-9dc7-d7c406b46e18...

So we have a customer using a Win32 gui app compiled with debug and a manifest calling for msvcr80d.dll trying to use mydll.dll which calls for msvcr80.dll.
He says it won't load.  I have tried everything I know of.  Placed msvcr80/msvcr80d in different places (like mydll direcotry, \windows\system32), copied the directory from /ms installdirecotry/Microsoft.VC80.CRT to the same directory containing mydll.dll

Answer 10

I must continue this thread in hopes of getting this thing resolved.  Just ban me if it gets too much.
To sum up I have a DLL compiled via command line and a manifest is created which I then inject into the DLL via "mt -manifest:mydll.dll.manifest -out:mydll.dll;#2". I compiled the dll with -MD,so it uses MSVCR80.DLL,and depends.exe shows it to be using the MSVCR80.DLL in /windows/winsxs.  All OK I think.
I have a customer program compiled with -MDd which is a WIM32 gui program.  It loads just fine on my development system with VS2005 and WinXP/SP3.  depends.exe shows it to be using the MSVCR80D.DLL in /windows/winsxs.
The customer says it does not load on his machine.  I am trying to get remote access to his machine, but I am not sure what to even look for. Like WHY would it work on mine but not his.

To further muddy things.  I have a sample program that uses my DLL also. If I compile it with -MTd, it works fine. BUT if I compile with -MDd, it does some weird things.
It is compiled in a totally separate directory from other stuff and only references MYDLL.LIB which is /jim/dll with the MYDLL.LIB in /jim/lib.
Now if I run depends in the sample/debug/sample.exe (the directory where I built it), it of course can't resolve the MYDLL.DLL because that is not in the path, BUT it does handily find MSVCR80D.DLL in /windows/winsxs.

THEN, when I copy the sample.exe to my application directory /jim/exe - now MYDLL.DLL is in the path. I run depends on my sample.exe program and now it finds the dlls; e.g.mydll.dll, BUT it cannot find MSVCR80D.DLL!! For some reason it thinks MSVCR80D.DLL should be in the same directory as the sample.exe (double clicked on MSVCR80D.DLL, which has the ugly question mark beside it.

Copying MSVCR80D.DLL to my application directory makes depends happy; now he can find it.  But running the program results in the R6034 error.

Am I nuts or what?  None of this is making any sense. 
I've been researching this stuff and reading every post I can find.  This stuff should be working - especially on a development machine.  And why does my customers program work on my machine but not on the machine he develops on (just like mine doesn't work on my development machine).

Thanks,

Jim

Answer 11

My last post apparently didn't make it.

I have found this out:
My build directory with IDE is /jim/sample. The executable goes into /jim/sample/debug/sample.exe.
My lib directory during the build is app/lib.
My runtime directory is /app/exe and my dll directory is app/dll.  Both are in my path when I try to run my sample.exe, but not, of course, during the IDE build.

If I copy the sample.exe to /app/exe and run it I get "this application failed to start because MSVCR80D.DLL was not found....".
depends sample.exe shows the MSVCR80D.DLL with the ugly "?" beside it.  Double click of that MSVCR80D.DLL shows it is "not found in /app/exe (well of course not). 
If I copy MSVCR80D.DLL to /app/exe, then I get the infamous R6034 error.

Now the weird part.  If i sit in my /app/exe directory and run /jim/sample/debug/sample.exe, then it works!!

"Deploying" my app to my runtime directory makes it not work! and this is all on the same development machine.

Why??  oh why??

Jim

Answer 12

Don't use Depends, it cannot track side-by-side DLLs properly.

---

Hans Passant.

Answer 13

I am using the depends from http://www.dependencywalker.com - version 2.2, which actually does seem to track side-by-side dlls.
The one shipped with VS2005 does not.

And BTW, the fact that depends does or does not track side-by-side DLLS seems to have little to do with solving my problem.

Thanks,

Jim