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