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.

  • I made the switch from VB to C# when Autocad went .NET route, glad I did, although it was a little painful at the time. VB is slowly falling away but C# if very strong. You have the same access to the CONNECT .NET api via either VB or C#. As we migrate to CONNECT we are maintaining a few of our major applications that were written in VB, but all minor applications are being rewritten in C# and all new development is done in C#. Must easier to bring new programmers on board using C# than VB at this point.

  • That's a good point about bringing new developers.

  • 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



  • Hi Viktor,

    I agree with Mike's and Bob's answers, they mentioned important points.

    From my perspective, there are at least two different topics in your question, or maybe better to say, your question can be answered from more perspectives (which Mike and Bob did).

    What language to use to work with NET API: As Bob wrote, everything ends as CIL instructions. It's the reason why different managed compilers (old compiler used up to VS2013, new Roslyn compiler, Mono etc.) exist and all they create assemblies compatible with NET Framework. So you can choose any NET (CLI) language, not only C# or VB.NET, but e.g. F#, C++/CLI or even more exotic langauges like IronPython, Eiffel etc. to create assembly that can be consumed by NET Framework and (when implemented properly) loaded by MicroStation as addin.

    What NET language to use: There is no "the best language for all projects" available. Every language is designed and developed with some intention, goals and priorities. From these reasons, the best language for general development is C#, because "C# is NET" and new features of NET runtime are developed in close relation to C# as main tool how to access these features. But when there is VB background, the transition to VB.NET is quite smooth and it was the main goal when VB.NET was designed. When you need to implement complex calculations or heavily multithreading / multitasking solution, maybe F# will provide more efficient tools to solve such problem.

    When talking about MicroStation, C# is the second best alternative generally (C++ API provides wider functionality and better performance), which means C# is the best from NET ;-)  And because C# is the most popular NET langauge and has pretty fast development (especially on NET.Core platform where C# 8 provides some extra features not available on NET Framework now), there is huge knowledge base available, plenty of books, tutorials etc.

    And one recommendation for the end: Invest time to learn to know at least basic how memory management and garbage collection works in NET (it's the same for VB.NET and C#). The most of tutorials and books simply state "You do not have to take care about memory, because garbage collector is responsible to do it." It's true, but not complete true, and my experience is that many people think "I know C# / VB.NET / whatever else", but they produce slow code where memory acess is just disaster. Of course it's more crucial when independent application is implemented, in MicroStation a lot of features are defined by API itself, but still such knowlege will always help you to wrote better code.

    With regards,

      Jan