From: David Ching on
"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
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


"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
"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


"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