Re: Re: chr() .Net equivalent
- From: Just_a_fan@xxxxxxxx
- Date: Thu, 10 Apr 2008 11:58:44 -0700
This is WELL SAID! You show great depth of experience. I hope folks
will take this as gospel!
Also, modifying make the new code unlike the old and a direct
comparison, later, to see if there was a simple conversion "typo" is out
the window, too. Make it in two (and a half) passes, as you mention.
1: Convert,
1.5 Make notes on anything to look at later
2: Fix on the new platform
Then as a new project, look at the notes from the conversion and the
output from the newly functioning program and rationalize any
differences.
A new platform may introduce differences of its own simply due to
changes in the underlying routines, even those of the same name which
have been modified by M$ or some other vendor. Then you are shooting at
a VERY moving target. You have the changes made during conversion and
changes on the new platform and/or called (purchased) routines and one
is not sure which change caused the different output. Then one might
have to back out the change, shoot the difference then put the change
back in causing triple work.
This should be in stone!
Mike
On Sun, 30 Mar 2008 23:07:13 +0100, in
microsoft.public.dotnet.languages.vb "\(O\)enone" <oenone@xxxxxxxxxxx>
wrote:
David Griffiths wrote:
I read many newsgroup articles that say it's better to (or more
correct) to write code without the VB namespace using just the
framework (if that's the correct analogy). Is there any advantage of
writing the code without the VB namespace....?
No.
Particularly if you're upgrading VB6 projects.
One of the things I've become very aware of over the last few years of
upgrading VB6 code to .NET is that it's very easy to "fix" things along the
way, tidying things up and generally improving things. While this seems like
a good idea, it's actually a major opportunity to add subtle bugs to your
code. As a result I now strongly advise my development team to simply
upgrade the code "as is", and worry about fixing things and tidying up
later.
If you start dropping Visual Basic functionality in order to simply avoid
referencing Microsoft.VisualBasic.dll, you'll break your code somewhere
along the line, it's almost inevitable. And for what? There's no benefit to
removing the reference to the DLL, it's a part of the framework so go ahead
and use it. The whole point of the .NET Framework is to provide rich
functionality to applications, and if you decide arbitrarily to ignore a
part of it then it'll just make your coding more difficult.
.
- Prev by Date: RE: One project running second project
- Next by Date: Vb.Net 2005 with ClickOnce and Crystal Reports
- Previous by thread: Re: chr() .Net equivalent
- Next by thread: Office 2007 typelib
- Index(es):
Relevant Pages
|
