David

According to various posters on this NG, you can open an older VB-Classic
project in a newer version of VB-Classic and it will upgrade it for you with
absolutely no problems.  From what they say, it's only when you try and
upgrade a project to .NET that it'll have difficulties.

It's ironic, because if I open a project I created using VS2002 in VS2008,
it upgrades in a matter of seconds, resolves all dependencies and I'm good
to go.

The VB/IDE when faced with a 'update conversion' errors on the side of
maintaining previous 'com' dependencies. i.e., a VB5 project converted to a
VB6 project will have its 'code' modified or warnings as to changes in the
runtime - but still attempts to allow the new project to run in its previous
environment. Thus dependencies are NOT automatically updated to run with
newer versions.  If the developer wishes to upgrade dependent components
then he is free to do so.

On development boxes that have had both environments installed (and this was
the general scenario) converting a VB5 project to VB6 is equally
transparent. In the OP's case - likely never having had VB5 installed - the
VB6/IDE correctly warns the developer that components the previous project
was dependent on are not available.

The OP then has the option, as Mr. Young{*filter*} pointed out, to either supply
older versions or update the project to used the newer installed versions.

The .Net Framework development environment - as most changes with an
'upgrade' are code only (or located in the framework or newer runtime, thus
no immediate impact) - has a far easier task.

Even so, I'm suspicious at the ease in which you claim VS2002 projects
'upgrade' to VS2008. I have found that while external dependencies are
seldom an issue there are few applications beyond the trivial that don't
load the task list with numerous items needing a bit of massage. In this
case - often useful to follow-through on.

-ralph

I appreciate the apples & oranges comparison - I'm referring however to the
many statements that certain posters here have made saying that they could
always upgrade from one version of classic VB to the next with no errors
whatsoever, and only when VB.NET came out did it cause them such terrible
heartache.  According to OP, it's not so problem free for classic VB
either...

And admittedly I cannot remember going from a VS2002 project to 2008 -
however I've opened VS2003 solutions in 2008 with no trouble at all, and
several have been very complex (1000's of lines of code, 6+ projects)
solutions.  And they've run exactly the same way, also.

--
2025
If you do not believe in time travel,
your beliefs are about to be tempered.

http://www.*-*-*.com/

| Ralph,
|
| I appreciate the apples & oranges comparison - I'm referring however to
the
| many statements that certain posters here have made saying that they could
| always upgrade from one version of classic VB to the next with no errors
| whatsoever, and only when VB.NET came out did it cause them such terrible
| heartache.  According to OP, it's not so problem free for classic VB
| either...
|
| And admittedly I cannot remember going from a VS2002 project to 2008 -
| however I've opened VS2003 solutions in 2008 with no trouble at all, and
| several have been very complex (1000's of lines of code, 6+ projects)
| solutions.  And they've run exactly the same way, also.
|
|
|
|

| >


| >> Surely it's not?
| >>
| >> According to various posters on this NG, you can open an older
VB-Classic
| >> project in a newer version of VB-Classic and it will upgrade it for you
| > with
| >> absolutely no problems.  From what they say, it's only when you try and
| >> upgrade a project to .NET that it'll have difficulties.
| >>
| >> It's ironic, because if I open a project I created using VS2002 in
| >> VS2008,
| >> it upgrades in a matter of seconds, resolves all dependencies and I'm
| >> good
| >> to go.
| >>
| >
| > This is a comparison between apples and oranges. The 'classic' VB
| > development platform Editor/IDE and the .Net Framework development
| > platform
| > Editor/IDE have little in common beyond the obvious analogies.
| >
| > The VB/IDE when faced with a 'update conversion' errors on the side of
| > maintaining previous 'com' dependencies. i.e., a VB5 project converted
to
| > a
| > VB6 project will have its 'code' modified or warnings as to changes in
the
| > runtime - but still attempts to allow the new project to run in its
| > previous
| > environment. Thus dependencies are NOT automatically updated to run with
| > newer versions.  If the developer wishes to upgrade dependent components
| > then he is free to do so.
| >
| > On development boxes that have had both environments installed (and this
| > was
| > the general scenario) converting a VB5 project to VB6 is equally
| > transparent. In the OP's case - likely never having had VB5 installed -
| > the
| > VB6/IDE correctly warns the developer that components the previous
project
| > was dependent on are not available.
| >
| > The OP then has the option, as Mr. Young{*filter*} pointed out, to either
| > supply
| > older versions or update the project to used the newer installed
versions.
| >
| > The .Net Framework development environment - as most changes with an
| > 'upgrade' are code only (or located in the framework or newer runtime,
| > thus
| > no immediate impact) - has a far easier task.
| >
| > Even so, I'm suspicious at the ease in which you claim VS2002 projects
| > 'upgrade' to VS2008. I have found that while external dependencies are
| > seldom an issue there are few applications beyond the trivial that don't
| > load the task list with numerous items needing a bit of massage. In this
| > case - often useful to follow-through on.
| >
| > -ralph
| >
| >
|
|