App local deployment with VC 2010
in [MFC]
|
From: David Ching on 27 May 2010 16:46 "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message news:e5l6Gvc$KHA.5560(a)TK2MSFTNGP02.phx.gbl... > > (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?) > Dependency Walker is not foolproof. I've seen it complain about some IE related file that is missing but if you google that error, everyone says just ignore it. So I'm not sure what the root cause is. > 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! > Sounds like some module of yours is still relying on VC9, be in a static library or other dependency. Since the contents of a manifest are stored in a built .exe/.dll as text, it's simple to search all your .exe's and .dll's for some string in the VC9 manifest, such as "Microsoft.VC90.CRT" and see what is the offending module. -- David
From: Hector Santos on 28 May 2010 00:02 This might be related but VS2010 either failed to convert VC6 projects or it did so intentionally and/or there is a bug. What I discovered in the VC++ directories that it kept, put the V6.0 SDK rather than use the V7.0A SDK path. That caused two things: - RC link problem with unknown switch -ologo - Included/mixed V6.0 headers with v7.0a headers causing some strange issuese, especially with intellisense Changeing/removeing the v6.0 SDK reference fixed it. However, I noticed the EXCLUDE DIRECTORIES had the v6.0 SDK reference, but only for the BIN I think, don't remember off hand. So if they intended that to resolved the INCLUDE it didn't. After setting it right, the compiler and intellisense was faster without a doubt. At least it seemed faster :) -- David Ching wrote: > "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message > news:e5l6Gvc$KHA.5560(a)TK2MSFTNGP02.phx.gbl... >> >> (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?) >> > > Dependency Walker is not foolproof. I've seen it complain about some IE > related file that is missing but if you google that error, everyone says > just ignore it. So I'm not sure what the root cause is. > > >> 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! >> > > Sounds like some module of yours is still relying on VC9, be in a static > library or other dependency. Since the contents of a manifest are > stored in a built .exe/.dll as text, it's simple to search all your > .exe's and .dll's for some string in the VC9 manifest, such as > "Microsoft.VC90.CRT" and see what is the offending module. > > -- David -- HLS
From: David Webber on 28 May 2010 07:22 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:BC1FC629-8D52-4A11-93DA-C013665D5D41(a)microsoft.com... > Sounds like some module of yours is still relying on VC9, be in a static > library or other dependency. Found it! I was explicitly loading it to find out what version it was to output in a diagnostic window. Code from years ago :-( > Since the contents of a manifest are stored in a built .exe/.dll as text, > it's simple to search all your .exe's and .dll's for some string in the > VC9 manifest, such as "Microsoft.VC90.CRT" and see what is the offending > module. But fixing that and getting rid of all the manifest stuff and all the mfc9 stuff still leaves me with a non-functioning program. I'm definitely going to have to bite the bullet, and start a new project and import the old code bit by bit. Still, that allows the opportunity of having trendy new things like a tabbed MDI :-) Every journey starts with a first step, as the proverb goes, so I'd better get going. Thanks for the help, everyone. 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 28 May 2010 09:13 "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message news:e06XLgl$KHA.4308(a)TK2MSFTNGP04.phx.gbl... > But fixing that and getting rid of all the manifest stuff and all the mfc9 > stuff still leaves me with a non-functioning program. > What is the error now? (Not Depends error, but the error you get when you run your program?)) -- David
From: David Webber on 28 May 2010 20:00 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:AEEAFDC7-8AA3-4061-B532-B60157F40FC3(a)microsoft.com... > "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message > news:e06XLgl$KHA.4308(a)TK2MSFTNGP04.phx.gbl... >> But fixing that and getting rid of all the manifest stuff and all the >> mfc9 stuff still leaves me with a non-functioning program. >> > > What is the error now? (Not Depends error, but the error you get when you > run your program?)) The splash panel comes up, and then it fails on loading the main frame, with "Mozart has stopped working: Windows is looking for a solution." :-) This is the release version, run outside Visual Studio. The Debug version run from Visual Studio is fine. I think I tinkered around with the manifest stuff so much for the VS 2008 version to get the release version working as app-local (with all sorts of conditional stuff on release or debug version) that its knickers are in a total proverbial twist. So... I have created a new vanilla VS 2010 project and confirmed that it runs as app-local on other machines, exactly as you said it would. I have so far imported two of my non-MFC DLLs wholesale, and called test functions within them, and they appear to be working. I'll create new projects for the MFC DLLs and import code carefully, doing some spring cleaning. It is more than a little complicated: one DLL has classed derived from CView, CDocument etc, and the three exe's have their own classes derived from the ones in the DL. That way all three exes use exactly the same drawing and file handling code (which is in the DLL) but still have their own menus. It will take a while, but I haven't created a new solution in ages, and I have now discovered I can have tabbed MDI, and tool bars to which the user can add buttons. And selectable themes. Not to mention a navigation pane. So users will get a radically new looking program out of all this work I'm doing - even if it doesn't yet include any new real functionality. I'll try to stop knocking the Windows fashion industry :-) :-) Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Product Version vs File Version Next: VS2010 - A Thing of Beauty! |