Upgrade 2008 to 2010

[Gale Green]

Hi all.

I've been reading on the MS web site till my eyes crossed and I've not
found the info that I need.

I have VS 2008, although I use only VB. If I upgrade to 2010 will my
existing apps build OK or will they require change?

Thanks for any guidance.

Gale.

 

[Armin Zingler]

Am 21.04.2010 11:21, schrieb Gale Green:

I've been reading on the MS web site till my eyes crossed and I've not
found the info that I need.

I have VS 2008, although I use only VB. If I upgrade to 2010 will my
existing apps build OK or will they require change?

AFAIK, the projects will be upgraded and not usable anymore
in VB 2008 afterwards. They should run like in VB 2008 with few
exceptions mentioned in your VB product documentation.

"Visual Basic 2010 Breaking Changes":
http://msdn.microsoft.com/en-us/library/cc714070.aspx

 

[Family Tree Mike]

Hi all.

I've been reading on the MS web site till my eyes crossed and I've not
found the info that I need.

I have VS 2008, although I use only VB. If I upgrade to 2010 will my
existing apps build OK or will they require change?

Thanks for any guidance.

Gale.
.

There is a conversion process for the solution files from VS 2005 or VS 2008
to VS 2010. I have not seen it modify the code files in these cases. The
project is converted to a VS 2010 project (or solution) and optionally backed
up prior to conversion. My recollection is that the new project in VS 2010
still refers to the previously set .net version, so the converted project
does not target the new .Net 4.0 framework.

Mike

 

[Cor Ligthert[MVP]]

Normally they wont require changes (be aware as long as you use framework
3.5)

You cannot use framework 4.0 if you have used the
Microsoft.VisualBasic.Compatible.VB6 namespace) the latter is normally only
if you have automatically converted from VB6.

If they run Ok?, View the link from Armin.

 

[Gale Green]

On Wed, 21 Apr 2010 13:07:34 +0200, Armin Zingler

Thanks to all who replied, and thanks for the link Armin. It doesn't
seem that I will fall foul of anything much (if at all).

Gale.

 

[Michel Posseth [MCP]]

Until sofar everything seems to work almost flawless over here
i encountered until sofar 2 problems with the conversions of my projects


1. if you have a solution with multiple projects you have the chance that
some files are converted twice , you can recognice this by the obvious
errors ( just removing the .1 versions wil solve this )

2. Some warning messages appear while the warning is total #$#% ( i
submitted this to microsoft connect with a screendump ) if you are not so
sure of yourself you might refactor the code while it is in fact perfectly
valid code

michel

 

[J.B. Moreno]

You cannot use framework 4.0 if you have used the
Microsoft.VisualBasic.Compatible.VB6 namespace) the latter is normally only
if you have automatically converted from VB6.

http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.compatibil
ity.vb6.aspx shows a lot of obsolete calls, but obsolete calls work....

 

[Gale Green]

Until sofar everything seems to work almost flawless over here
i encountered until sofar 2 problems with the conversions of my projects


1. if you have a solution with multiple projects you have the chance that
some files are converted twice , you can recognice this by the obvious
errors ( just removing the .1 versions wil solve this )

2. Some warning messages appear while the warning is total #$#% ( i
submitted this to microsoft connect with a screendump ) if you are not so
sure of yourself you might refactor the code while it is in fact perfectly
valid code

Thanks for the extra info Michel.

Gale.

 

[Cor Ligthert[MVP]]

Hi,

Thanks for this information, I really had the idea that it was described in
the same time as the upgrade facility.

I see now that this is only for 64bits where it is not available while
available for 32bits.

Cor

 

[J.B. Moreno]

-snip cannot use both 4.0 and Microsoft.VisualBasic.Compatibility.VB6-
-snip yes you can, just obsolete now-

Hi,

Thanks for this information, I really had the idea that it was described in
the same time as the upgrade facility.

I see now that this is only for 64bits where it is not available while
available for 32bits.

Thanks, I almost missed the fact that the obsolete attribute on the
methods include a notice that they are 32 bit only.

 

[Phill W.]

-snip cannot use both 4.0 and Microsoft.VisualBasic.Compatibility.VB6-
-snip yes you can, just obsolete now-

Which, of course, implies that in a future release - /any/ future
release - they could be removed.

Regards,
Phill W.

 

[J.B. Moreno]

Which, of course, implies that in a future release - /any/ future
release - they could be removed.

Yep -- in THAT release. And they *might* do that in 2012 or whenever
the next major release is (I doubt they'll do it for a minor release).

Thinking about it, I'd guess that the reason for marking things
obsolete has something to do with ADODC, and wanting to support 64bit
systems better. I'd guess that they won't be dropped until there's a
64 bit version of Visual Studio. Which I wouldn't bet on happening
anytime soon.

 

[Phill W.]

Yep -- in THAT release. And they *might* do that in 2012 or whenever
the next major release is (I doubt they'll do it for a minor release).

I don't think anyone [then] would have bet on a Service Pack for MS
Office rendering [millions of] MS Word documents unreadable, but that
didn't stop our Friends in Redmond ...
http://support.microsoft.com/kb/938810

Regards,
Phill W.

 

[J.B. Moreno]

Yep -- in THAT release. And they *might* do that in 2012 or whenever
the next major release is (I doubt they'll do it for a minor release).

I don't think anyone [then] would have bet on a Service Pack for MS
Office rendering [millions of] MS Word documents unreadable, but that
didn't stop our Friends in Redmond ...
http://support.microsoft.com/kb/938810

There's a big difference between file types that are a security risk,
and obsolete code.

(Not sure whether or not dropping back a version of the framework
should be considered the equivalent of changing a registry setting in
order to re-enable the file types).

Anyway, yeah it's possible they could do so in a minor framework
release, but I'd bet against it.

Although, frankly, I'm at a bit of a loss as to why they'd even bother
marking them obsolete.

The only people that have much of a choice in using it are the
migration tools. They aren't providing a migration tool themselves now
and the independent tools that do migration aren't going to change just
because it's marked obsolete. They are going to use it where it seems
best and provide something else where /that/ seems best (forex it looks
like VB Migration Partner isn't going to use ADODB much longer and
that's what I see as the most significant portion of the compatibility
namespace).

Most developers are simply going to let it be and ignore it, not start
rewriting their migrated code just to get rid of a warning.