DateDiff equiv in C#??

  • Thread starter Thread starter SilentCry
  • Start date Start date
Jimi,

I suppose the bagagde would be an extra assembly being loaded into your
application domain, when all you need is one small function. Most likely a
very
trivial size increase, but non the less, excess bagage ;)

And no worries on the thread, I, personnaly, enjoy when we get a thread
which
has a longer life then QA posts. This is where people get a chance to learn
and
to take part of other (some times more skilled) developers share thier
thoughts.

//Andreas

Jimi said:
Sorry about the tone of my last post, but all I'm trying to say is
that if there's a VB method you're used to, then by all means just
keep using it - no fuss, no muss. Personally, I've replaced some
with my own versions, but I began to realize I was just doing it for
purity's sake, not because it made financial sense to recode what was
there already. There's no extra baggage - Microsoft.VisualBasic is
part of the framework.

If the VB methods were from another namespace, called say
"System.SuperDuper", then we wouldn't even be having this discussion.
Click to expand...
 
Jon said:
[...]
There's no extra baggage - Microsoft.VisualBasic is part of the framework.
Click to expand...

Well, that depends on what you really think of as "the framework". It's
certainly not "core" [...]
Click to expand...

Wouldn't using routines from that namespace mean that your application
has to distribute the old VB runtime DLLs with it?
 
No, the routines in the Microsoft.VisualBasic does not depend on the
VB runtimes, but mimics the functions with normal .NET code. It has
just been included to help VB developers

(1) Port VB applications
(2) Provide transitional functionality when you move to .NET,
since you will look for (example) DateDiff, but in .NET there
is no such function.

I would say that the main reason is (1) so developers can port thier
VB(6) applications with a wizard.

//Andreas

C# Learner said:
Jon said:
[...]
There's no extra baggage - Microsoft.VisualBasic is part of the
Click to expand...
framework.

Well, that depends on what you really think of as "the framework". It's
certainly not "core" [...]
Click to expand...

Wouldn't using routines from that namespace mean that your application
has to distribute the old VB runtime DLLs with it?
Click to expand...
 
C# Learner said:
Well, that depends on what you really think of as "the framework". It's
certainly not "core" [...]
Click to expand...

Wouldn't using routines from that namespace mean that your application
has to distribute the old VB runtime DLLs with it?
Click to expand...

No - they're not actually using the VB runtime at all (I believe) - the
methods are rewritten in .NET, they just (hopefully) do the same thing
as their VB counterparts.

That's the way I understand it, anyway.
 
Jon,

Yes this is the case, I did some snooping with Reflector
to confirm my suspicions. Albough I did only check a few of
the members in the namespace, I boldly draw the conclusion
it applies to them all :)

//Andreas

Jon Skeet said:
C# Learner said:
Well, that depends on what you really think of as "the framework". It's
certainly not "core" [...]
Click to expand...

Wouldn't using routines from that namespace mean that your application
has to distribute the old VB runtime DLLs with it?
Click to expand...

No - they're not actually using the VB runtime at all (I believe) - the
methods are rewritten in .NET, they just (hopefully) do the same thing
as their VB counterparts.

That's the way I understand it, anyway.
Click to expand...
 
Andreas said:
Jon,

Yes this is the case, [...]
Click to expand...

Ah, I just presumed that MS went the lazy route and used the existing VB
DLLs. It seems that they've gone a long way to help the Win32 VB developer.

Thanks for the info.
 
Tom,

I would suspect it would be more of a problem to marshal back and
forth between a VB dll than just mimicing the functions =)

//Andreas

C# Learner said:
Andreas said:
Jon,

Yes this is the case, [...]
Click to expand...

Ah, I just presumed that MS went the lazy route and used the existing VB
DLLs. It seems that they've gone a long way to help the Win32 VB developer.

Thanks for the info.
Click to expand...
 
J.V,

Well that is not quite true, since first of all TimeSpan is a struct
where as
DateDiff is a method (actually two overloaded methos) in the DateAndTime
class. The functionality of the two are also not interchangeable.

//Andreas
 
Back
Top