microsoft.visualbasic namespace obsolete?

  • Thread starter Thread starter cj
  • Start date Start date
C

cj

I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???
 
I am under the impression they are obsolete methods included for
backward compatibility. For instance is using
filedatetime("c:\myfile.txt") still the accepted way of getting the date
c:\myfile.txt was last modified? I see filedatetime is in the
Microsoft.VisualBasic namespace. Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to
learn the new way of doing things but frequently I find the new way is
longer and seems more confusing. Like my example filedatetime(). It'll
do what I need now but should I look for something else???
Click to expand...

You'll get a lot of different opinions on this issue. Largely, what
you should do depends on what you plan to do in the future.

If you're planning to become a hard-core .NET developer, you should
definitely learn the .NET way of doing things. (This is especially
true if you want to learn other .NET languages.) The
Microsoft.VisualBasic namespace does include a lot of stuff that is
there to ensure that VB6 code is portable to .NET; we are encouraged
to move away from that namespace to the functionality provided by the
core System namespaces.

The real value of that depends on a number of factors. Is the code
going to be ported to other languages? Will it be used by other
systems? Is it a code library? Or is it a self-contained application
that's a one-shot and not likely going to be used anywhere else?
Practicality should always govern what you decide to do. However,
practicality does *not* mean that you should always have blinders on,
or suffer from a very narrow world view.

Plan for the future. My suggestion is that you keep at it, and move
away from the Microsoft.VisualBasic namespaces. The payoff is
worthwhile. The C# samples that are pervasive don't use that
namespace; you'll find that they're much easier to understand and port
to Visual Basic.NET if you know what they're doing. :) Further, the
pain customary to the learning period is short-lived; once you know
it, you *know* it, and you'll have much more value to everyone.

I hope I haven't overwhelmed you. (I tend to do that sometimes.)

Cheers!
Mike Hofer
 
I am under the impression they are obsolete methods included for
backward compatibility.
Click to expand...

They are not obsolete.

Is there some

dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?
Click to expand...

System.IO.File.GetLastWriteTime is the alternative - use whatever you
like best.


Mattias
 
cj said:
I am under the impression they are obsolete methods included for backward
compatibility.
Click to expand...

That's a wrong impression.
dim file as new something
dim lastchanged as date = file.datetime

method we are supposed to use now?

If so what would make it better than filedatetime("c:\myfile.txt")???

I try to avoid functions in microsoft.visualbasic because I want to learn
the new way of doing things but frequently I find the new way is longer
and seems more confusing.
Click to expand...

There is no "new way". There is only more than one way. Take a look at the
classes in the 'System.IO' namespace, namely 'File'.
 
You mean that in the BeNeLux would exist in future only Netherlands way of
life, because the other countries are obsolete. In my idea are the Belgian
and Luxenburg cultures full part of it. Like the MicosoftVisual Basic
namespace is in the Net.

Cor
 
cj said:
I am under the impression they are obsolete methods included for
backward compatibility.
Click to expand...

Not so.
Those in MS.VB./Compatibility/ should be used with caution - it contains
those things that we used to use all the time, but have now "grown out"
of, like fixed length strings. They are intended /only/ to get your
application migrated to .Net and from there, you can rewrite bits of it
as necessary.
is using filedatetime("c:\myfile.txt") still the accepted way of getting
the date c:\myfile.txt was last modified?
Click to expand...
It's still there; it still works and it's not going anywhere.
Is there some ... method we are supposed to use now?
Click to expand...

The FileInfo class wraps this up.
I try to avoid functions in microsoft.visualbasic ...
Click to expand...

Some people try to go as far as removing the MS.VB from Visual Basic,
but since the compiler /itself/ makes use of some of the stuff in here
(try creating a VB.Net program that doesn't depend on this assembly!),
it's a pretty pointless exercise.
... because I want to learn the new way of doing things but frequently I
find the new way is longer and seems more confusing.
Click to expand...

Agreed.
Anyone found the "new" way of 'ReDim'ing an array?

HTH,
Phill W.
 
Thanks to everyone for your responses. I'm glad microsoft.visualbasic
is still acceptable, I'll stay away from the Compatibility namespace and
thanks for the tip on system.io.file.
 
"Anyone found the "new" way of 'ReDim'ing an array?"

Actually, you can use Array.Resize (the behavior is identical to ReDim
Preserve, but it's limited to single dimension arrays). But ReDim Preserve
still works fine.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
 
You will find some opposition with people who insist on 'pure' .NET
approaches. Some very useful parts have no equivalent in the rest of the
framework, such as the Financial class.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
 
Phill,

I had not the idea that many people are still using the Microsoft
VisualBasic Compatiblility namespace.
It is a temporary namespace, however not containing the members from the
Microsoft Visual Basic namespace we are talking about at the moment. I for
sure would not advice to use that Compatibility namespace withouth the
conversion software.

Cor
 
David,

Pure Net approaches needs the Microsoft Visual Basic Namespace the same as
the System.namespace.

That it is possible to work seperately on namespaces is one of the
advantages from .Net

Nobody will tell it there will be more namespaces in Net.

Cor
 
I don't have a problem with Microsoft.VisualBasic (especially from VB code),
but I'm just indicating the type of respone that some people will give you if
you use it.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: C#/VB to C++ converter
Instant Python: C#/VB to Python converter
 
Cor, he didn't recommend using the compatibility namespace, just said it
was ok to use microsoft.visualbasic.
 
David said:
"Anyone found the "new" way of 'ReDim'ing an array?"

Actually, you can use Array.Resize (the behavior is identical to ReDim
Preserve, but it's limited to single dimension arrays). But ReDim Preserve
still works fine.
Click to expand...

Ah! Finally!

New to /'2005/ though, and I'm still trudging around with '2003.

Maybe one day ...

Many Thanks,
Phill W.
 
Phill said:
Ah! Finally!

New to /'2005/ though, and I'm still trudging around with '2003.

Maybe one day ...

Many Thanks,
Phill W.
Click to expand...

You can easily do the same in framework 1. Just create a new array and
use Array.Copy to copy the values from the old array. That's how
Array.Resize does it.
 
Back
Top