App local deployment with VC 2010
in [MFC]
|
From: David Webber on 26 May 2010 18:16 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 26 May 2010 18:47 "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 27 May 2010 09:48 "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 27 May 2010 10:50 "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 27 May 2010 14:38
"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 |