2

I've been researching the best way to accomplish a semi-trivial task in my C# application and the answer which seems the simplest to implement involves referencing the Microsoft.VisualBasic namespace. (Specifically I am doing CSV processing and wanting to use the TextFieldParser class, but that isn't really relevant to this question).

What is the effect that this has on my application? I know it will be referencing yet another namespace in the .NET framework but is it any different than referencing any of the other ones? What is the point of having a separate VisualBasic namespace at all?

I'm not totally opposed to everything Visual Basic (it is just another syntax for writing .NET applications) but I would just like to understand why there is a separate namespace just for VB and the implications of using it in a C# application. I don't like just blindly using and relying on something that I don't understand.

There is this question: Is the Microsoft.VisualBasic namespace "true .NET" code? but it doesn't really fully answer my question about what impact including this namespace will have on my application. (Plus what about the 1 out of 10 calls that AREN'T just wrappers?)

Community
  • 1
  • 1
Mike D.
  • 4,034
  • 2
  • 26
  • 41
  • 1
    There's nothing wrong with that.. other than the fact there are better third party libraries out there for CSV parsing/processing (that are written in C# :)). – Simon Whitehead Apr 08 '14 at 04:17
  • 2
    You don't reference *namespaces*, you reference *assemblies*. A single assembly may contain types in multiple namespaces. Multiple assemblies may contain types within a single namespace. – Damien_The_Unbeliever Apr 08 '14 at 06:15
  • @Damien_The_Unbeliever thanks for the clarification on references. It hadn't fully clicked in my head what the differences between using a namespace and referencing something where until your comment. – Mike D. Apr 08 '14 at 06:18

1 Answers1

0

There is nothing wrong or special about including Microsoft.VisualBasic.dll assembly for Microsoft.VisualBasic.FileIO.TextFieldParser class.

  • more assemblies may mean longer load time (if referred early in code), but if you need some functionality it has to come from somewhere - so unlikely to be serious issue.
  • this is not "System" assembly, so it is somewhat less likely to be ported to other runtimes. Classes you are looking for are available in Mono, so not much of a concern, may want to double check for WinRT support if needed.
  • specialized libraries may provide more flexibility, but Microsoft.VisualBasic already present in .Net so if its functionality is enough for your case it may simplify setup.
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • Thanks for also pointing out that this isn't in System, it is a separate assembly. Your answer and Damien's comment above about referencing assemblies and not namespaces has cleared up my confusion. The Microsoft.VisualBasic assembly is just where all (most?) of the VB.NET methods/classes/etc live and referencing it from my C# simply adds a reference to another assembly (aka DLL). – Mike D. Apr 08 '14 at 06:22