>> I hate to say it but, I feel it must be said:
>>
>> You can use the VB.NET libraries from with C#
>>
> ...but why you would go to such great lengths to do this is
> beyond me. Especially when if you look at the IL for StrDup
> all it's doing is what you should be anyway: calling new
> String('-', 65).
>
> You're also paying the price of that additional error
> handling. This is common throughout all the compatibility
> APIs. Honestly, VB.NET people would be doing themselves a
> favor if they quickly learned to let go of the quick
> and dirty VB shortcut functions of old and found
> their BCL equivalents. Granted, some of the functions
> actually do provide useful services beyond
> the BCL, but that's the exception not the norm.

Well I did say I hated to mention it (mostly for the
reasons you oulined)...

But I thought it was worth pointing out that VB.NET
doesn't have any libraries that you cannot use from C#
(Least not that I am aware of) and they are all there
available to use from C#.

Whether it is sensible to use them or whether you
want to use them is a different matter entirely...

Just so you know my other reasons for not using them
is I find it more interesting to find a different way of
doing things with the CLR, than would have been done
before it, after all its there to make things eaiser
- it adds a bit of spice to developing, and you learn
a lot in your searches. And my other is that I don't like
using any builtin namespace that does not begin 'System'
but thats just my little prejudice.

As you say, I admit if i were to want a double
specifying the principal payment for a given period
of an annuity based on periodic, fixed payments and
a fixed interest rate; I be lazy and use
Microsoft.VisualBasic.Financial.PPmt, rather than
coding it up, but thats just me I suppose... ;-)

Jeremy :)

You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to