From: David Webber on
Ok, the bad guys *were* waiting behind the rocks.

I removed all the manifest stuff from the RC files, and tried deploying with
mfc100u.dll msvcr100,dll and msvcp100.dll in the same directory as the exe,
and no sign of any manifests.

It tries to run but.....

Dependency walker tells me that GPSVC.DLL and IESHIMS.DLL (which should be
delay-loaded) can't be found. The dependency of the system DLLs seems to
be

user32.dll - advapi32.dll - *wintrust.dll - crypt32.dll - *userenv.dll -
*gpsvc.dll

shell32.dll - *devmgr.dll - *shdocvw.dll - ieframe.dll - *ieshims.dll

[where * are delay loaded.]. It seems to be happy until it drills down
to gpsvc.dll and ieshims.dll. I'm baffled as to why it can't find these
so deep in the tree of system DLLs.

Any ideas?

Dave
--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm


From: David Ching on
"David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
news:egimpES$KHA.420(a)TK2MSFTNGP02.phx.gbl...
> Ok, the bad guys *were* waiting behind the rocks.
>
> I removed all the manifest stuff from the RC files

I successfully created an MFC app using VS2010 Appwizard, built RELEASE
version with shared MFC DLL. I copied it into a VM without VS2010 installed
and ran it. Got missing DLL message for MFC10<something>. Good.

I copied *all* MFC and CRT redist DLL's (and not just the few you mentioned)
into same folder as .exe and ran again. It worked.

But the .exe has a barebones manifest file in it. It had a dependency on
Common Controls 6, and also set the asInvoker privilege level. I disabled
creation of this manifest by going into the project Properties: Manifest
Tool | Input and Output | Embed Manifest "No"

I rebuilt and copied new .exe into VM (into the folder with the redist DLL's
already in it). It still ran OK.

So I recommend you try again and this time copy *all* MFC and VC redist
DLL's into same folder as .exe.

(The previously supported way of copying e.g. the entire
Microsoft.VC100.MFC\ folder and putting it as a sub-folder of your .exe
doesn't work anymore. Instead, you need to put the DLL's within this folder
into the same folder as your .exe, which you were already doing. )

-- David

From: David Webber on
"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:ukl4fVS$KHA.5916(a)TK2MSFTNGP04.phx.gbl...
> "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
> news:egimpES$KHA.420(a)TK2MSFTNGP02.phx.gbl...
>> Ok, the bad guys *were* waiting behind the rocks.
>>
>> I removed all the manifest stuff from the RC files
>
> I successfully created an MFC app using VS2010 Appwizard, built RELEASE
> version with shared MFC DLL. I copied it into a VM without VS2010
> installed and ran it. Got missing DLL message for MFC10<something>.
> Good.
>
> I copied *all* MFC and CRT redist DLL's (and not just the few you
> mentioned) into same folder as .exe and ran again. It worked.
>
> But the .exe has a barebones manifest file in it. It had a dependency on
> Common Controls 6, and also set the asInvoker privilege level. I disabled
> creation of this manifest by going into the project Properties: Manifest
> Tool | Input and Output | Embed Manifest "No"
>
> I rebuilt and copied new .exe into VM (into the folder with the redist
> DLL's already in it). It still ran OK.
>
> So I recommend you try again and this time copy *all* MFC and VC redist
> DLL's into same folder as .exe.

I'm pretty sure they aren't necessary - the Unicode MFC library, CRT and C
and C++ runtimes are all I have used in the VS2008 version. But I tried
anyway and no luck. I also tried the "Embed Manifest No" in the EXE and all
my DLLs, and now the whole thing crashes even when running in Visual Studio.
So I set the manifests back, and it still crashes in Visual Studio. :-(

Time to recover the back-up. :-)

[Or maybe, as my projects have been upgraded through various versions of
Visual Studio, it may be time to bite the bullet and create entirely new
project files and gradually fill them with my old code. That's quite a big
task though as there are 3 exes, 10 dlls and many thousands of files.]

Dave
--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm

From: David Ching on
"David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
news:exCw4Na$KHA.5808(a)TK2MSFTNGP02.phx.gbl...
> [Or maybe, as my projects have been upgraded through various versions of
> Visual Studio, it may be time to bite the bullet and create entirely new
> project files and gradually fill them with my old code. That's quite a
> big task though as there are 3 exes, 10 dlls and many thousands of files.]
>

Yeah, maybe that's the way to go. I find myself doing that more and more,
not with VC++ projects but with 3rd party .NET UI controls that as I update
to newer versions of the library, my existing usage isn't exactly right
which is fixed simply by deleting the control and re-adding it from the
toolbox and then the library's new designer code instantiates and sets
default properties correctly for the new version.

Upgrading to new versions of anything is tedious and relegates us developers
to the role of assembly workers. "Drop this into that and watch dumbly
while something else we don't control sets it up. Need to know exactly what
the problem is? Diff the generated files and find the differences." Not
exactly why I signed up for this, which is why I update as little as
possible! :-)

-- David

From: David Webber on


"David Ching" <dc(a)remove-this.dcsoft.com> wrote in message
news:2FDF0567-72E7-4AB4-BB5A-95857B15F5A8(a)microsoft.com...
> "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message
> news:exCw4Na$KHA.5808(a)TK2MSFTNGP02.phx.gbl...
>> [Or maybe, as my projects have been upgraded through various versions of
>> Visual Studio, it may be time to bite the bullet and create entirely new
>> project files and gradually fill them with my old code. That's quite a
>> big task though as there are 3 exes, 10 dlls and many thousands of
>> files.]
>>
>
> Yeah, maybe that's the way to go...

Found a new weirdness.

Put my project back together form the backup, and built the release version
in VS 2010.

Dependency walker tells me there's a dependence on MSVCR100.DLL and
MFC100U.DLL

No sign of the old MSVCR90.DLL and MFC90U.DLL - good.

(It still reports the missing system DLLs, but the exe runs fine in situ,
where it was built with VS 2010, both from the IDE and by launching the exe
without the IDE. Not sure how that happens?)

However some old files are still in the folder: Microsoft.V90.MFC.manifest
and Microsoft.V90.CRT.manifest which are all to do with with the old
versions of the DLLs, which are supposedly no longer used. (Though
mfc90u.dll and the 9.0 CRT *are* in the folder for historical reasons).
But if I delete the manifest files and try to run the program - bingo! All
sorts of message boxes pop up telling me I'm not loading DLLs properly.
Looks like its's trying to use v9.0 of MFC and CRT despite what dependency
walker says. I thought the VS 2010 conversion of the project would have
changed that, and dependency walker seemed to thinks so.

Confused!

Dave
--
David Webber
Mozart Music Software
http://www.mozart.co.uk
For discussion and support see
http://www.mozart.co.uk/mozartists/mailinglist.htm