>> 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.
