VB.NET vs C# limitations in Connect .NET API

I have no problem reading and modifying c# code, but I am definitely more fluid in vb.net, and since majority of my code (80/20) is already in vb.net, I am trying to figure if there are any limitations with vb.net in relationship to Microstation Connect .NET api. From the examples and little bit of testing that I have done, I don't see anything, but I also noticed that all of the samples are in C# and most of the discussions are related to C#. 

With AutoCad, most of developers that used COM and VBA API continued to use VB.NET when .NET api got published, so did I, c# was mostly used by those that converted from VLISP, which I never grew to like much. 

Anyway, I have no problem with the fact that examples are in C#, and I understand I can just recompile some of my own classes in C# and that would give me a good head start, but still wanted to see if I am missing something.

Thanks.

Parents
  • Hi ,

    Fwiw.

    In addition to Mike's good use-case advice, historically a large portion of MicroStation's code base (and extensions) has been written primarily in C++, C, and C# .NET. 

    Since most MicroStation developers have specialization in writing C-style programming languages, and 3rd party "MDL" applications (and respective community developers) also write and support C-style languages; it makes it easy to copy and paste (or write pseudo-code on-the-fly) to make helping each other out quickly.

    Other than these primary historic/majority reasons, any Microsoft .NET language goes through the MSIL compilers and ends up (mostly) being syntax differences, (your) personal developer preference, and/or ease of being able to communicate/translate between various .NET "recommendations" received and provided.

    Bob



Reply
  • Hi ,

    Fwiw.

    In addition to Mike's good use-case advice, historically a large portion of MicroStation's code base (and extensions) has been written primarily in C++, C, and C# .NET. 

    Since most MicroStation developers have specialization in writing C-style programming languages, and 3rd party "MDL" applications (and respective community developers) also write and support C-style languages; it makes it easy to copy and paste (or write pseudo-code on-the-fly) to make helping each other out quickly.

    Other than these primary historic/majority reasons, any Microsoft .NET language goes through the MSIL compilers and ends up (mostly) being syntax differences, (your) personal developer preference, and/or ease of being able to communicate/translate between various .NET "recommendations" received and provided.

    Bob



Children
No Data