Coffeehouse Thread

33 posts

C# and VB.NET don't play well together???

Back to Forum: Coffeehouse
  • User profile image
    phreaks

    It's been awhile since I've done much VB.NET development.

    Anyway I was putting together a solution that contains 2 projects with identical structures.    

    One in C# and the other in VB.Net to illustrate some of the diffs to our VB.NET devs.

    I just cranked out a very simple class for each language.
    All it does is Traverse a Directory and adds info about the files into a Dictionary<String, FileAttributes>

    Everything complied fine, and the NUnit test for each respective project run fine. For giggles, I thought I would write a test that compared the execcution time of each implementation, just because I am curious.

    When I try to access the VB.NET colection from C#, it throws me an error.

    NUnit Errors wrote:

    NetDemo.CDemo.Tests.CDemoTests.TimedCommandExecutionTest : System.InvalidCastException : Unable to cast object of type 'System.Collections.Generic.Dictionary`2[System.String,Microsoft.VisualBasic.FileAttribute]' to type 'System.Collections.Generic.Dictionary`2[System.String,System.IO.FileAttributes]'.


    The Offending Line of Code in my C# Test is this.

    vbfileCollection = (Dictionary<String, System.IO.FileAttributes>)myVBFileCmd.Results;

    If I try to change the Code to
    vbfileCollection = (Dictionary<String, Microsoft.VisualBasic.FileAttribute>)myVBFileCmd.Results;

    It tells me that there is no FileAttribute Member in Microsoft.VisualBasic. 

    WTF?

    Does anyone know exactly what I am doing 'wrong' here, and better yet why this doesn't work?

    I thought all the .NET languages were pretty much interchangable?

    ==============================================
    The C# Test Code that Calls VB.Net Code
    ==============================================
    VBDemo.Commands.
    FileListCommand myVBFileCmd = new NetDemo.VBDemo.Commands.FileListCommand(directoryPath);

    myVBFileCmd.Execute();

    vbfileCollection = (Dictionary<String, System.IO.FileAttributes>)myVBFileCmd.Results;

    ================================================
    VB Runtime Code
    ================================================

    Namespace NetDemo.VBDemo.Commands

    Public Class FileListCommand
       Inherits BaseCommand

    Private _fileCollection As Dictionary(Of String, FileAttribute) = New Dictionary(Of String, FileAttribute)

    Private _dInfo As DirectoryInfo
    Public Sub New(ByVal filePath As String)
       MyBase.New()
       _dInfo =
    New DirectoryInfo(filePath)
    End Sub

    Public Overrides Sub Execute()

    Dim fInfo() As FileInfo

    Try
       fInfo = _dInfo.GetFiles()
       For Each f As FileInfo In fInfo
          _fileCollection.Add(f.Name, f.Attributes)
       Next
    Finally
       MyBase._results = Me._fileCollection
    End Try

    End Sub

    End Class

    End Namespace


  • User profile image
    Cannot​Resolve​Symbol

    Try changing:

    Private _fileCollection As Dictionary(Of String, FileAttribute) = New Dictionary(Of String, FileAttribute)

    to

    Private _fileCollection As Dictionary(Of String, System.IO.FileAttributes) = New Dictionary(Of String, System.IO.FileAttributes)

    They're most likely not the same type and therefore not compatible.

    The trouble with VB (or the advantage, if you think of it that way) is that it gets its own library that nothing else has direct access to.

    You may also have to change some other things in the VB code to match the appropriate class in System.IO, but I'd just try this first.

  • User profile image
    Cannot​Resolve​Symbol

    phreaks wrote:
    
    CannotResolveSymbol wrote: 

    Try changing:

    Private _fileCollection As Dictionary(Of String, FileAttribute) = New Dictionary(Of String, FileAttribute)

    to

    Private _fileCollection As Dictionary(Of String, System.IO.FileAttributes) = New Dictionary(Of String, System.IO.FileAttributes)

    They're most likely not the same type and therefore not compatible.

    The trouble with VB (or the advantage, if you think of it that way) is that it gets its own library that nothing else has direct access to.



    Thanks, you def pointed out the problem, but the solution doesn't work.

    Apparantly, there is no FileAttribute Member of System.Io in VB?
    Can that even be possible, or am I on LSD again?


    FileAttributes

  • User profile image
    phreaks

    CannotResolveSymbol wrote:
    

    Try changing:

    Private _fileCollection As Dictionary(Of String, FileAttribute) = New Dictionary(Of String, FileAttribute)

    to

    Private _fileCollection As Dictionary(Of String, System.IO.FileAttributes) = New Dictionary(Of String, System.IO.FileAttributes)

    They're most likely not the same type and therefore not compatible.

    The trouble with VB (or the advantage, if you think of it that way) is that it gets its own library that nothing else has direct access to.



    Thanks, you def pointed out the problem.

    EDIT:// whoops, lemme try your solution

  • User profile image
    phreaks

    CannotResolveSymbol wrote:
    
    phreaks wrote: 
    CannotResolveSymbol wrote: 

    Try changing:

    Private _fileCollection As Dictionary(Of String, FileAttribute) = New Dictionary(Of String, FileAttribute)

    to

    Private _fileCollection As Dictionary(Of String, System.IO.FileAttributes) = New Dictionary(Of String, System.IO.FileAttributes)

    They're most likely not the same type and therefore not compatible.

    The trouble with VB (or the advantage, if you think of it that way) is that it gets its own library that nothing else has direct access to.



    Thanks, you def pointed out the problem, but the solution doesn't work.

    Apparantly, there is no FileAttribute Member of System.Io in VB?
    Can that even be possible, or am I on LSD again?


    FileAttributes


    Yeah, thanks, that works, I caught that on the second read.
    Why don't they have the same classes?
    Weird, also something else that I didn't expect.

    C# takes 6 milliseconds to execute, VB took 2 milliseconds.

    I would have thought C# would have executed faster...

  • User profile image
    Cannot​Resolve​Symbol

    phreaks wrote:
    Yeah, thanks, that works, I caught that on the second read.
    Why don't they have the same classes?
    Weird, also something else that I didn't expect.

    C# takes 6 milliseconds to execute, VB took 2 milliseconds.

    I would have thought C# would have executed faster...


    Wonderful Smiley

    I would think C# would execute faster, too...

    I'd guess that they don't have the same classes to provide a little bit of backwards compatibility with earlier versions of VB, or maybe to "simplify" things for developers.

    I lean towards the backwards compatibility explanation myself (but I'm not an MS developer, so take this how you will)...  if you look at Microsoft.VisualBasic.FileAttribute, you'll see that it only has the basic file attributes defined in FAT32 (ReadOnly, System, Hidden, Archive), while System.IO.FileAttributes has all the stuff you'd expect out of NTFS:  Compressed, Encrypted, Hidden, ReparsePoint, etc.

  • User profile image
    zian

    I think it's backward compatiblity too. Whenever you install a VB .NET program, Microsoft.VisualBasic.Compatibility.dll comes along with it. The description of the DLL is "Visual Basic Compatibility Runtime Library."

  • User profile image
    Ang3lFir3

    IIRC the Microsoft.VisualBasic Namespaces purpose is partly to provide compatability with the Visual Basic runtime.... It should not be used unless absolutely necessary. IT provides a way of using Classic VB syntax to create code that compiles in VB.NET.

    What CanNotResolveSymbol said is absolutely true.... they are not the same type. Microsoft.VisualBasic.FileAttribute representing the older Classic VB.

    As a VB.Net dev I take great delight when C# devs get a little more insight into how their impressions of VB.NET could be wrong(not saying yours were). Or maybe its just that we VB.NET devs can type faster ( Tongue Out ohh I kid)

  • User profile image
    JChung2006

    When faced with problems like this, the Object Browser (Ctrl-Alt-J) is your friend.

    I'm not sure why people think C# is faster than VB.NET.  Both compile to IL.

  • User profile image
    Ion Todirel

    JChung2006 wrote:
    I'm not sure why people think C# is faster than VB.NET.  Both compile to IL.
    C# has pointers. You can directly manipulate memory like in C/C++.

  • User profile image
    AndyC

    JChung2006 wrote:

    I'm not sure why people think C# is faster than VB.NET.  Both compile to IL.


    C# has unsafe blocks, allowing for lower level manipulation and thus potential speed improvements. Also, they have different optimisers which can make all the difference, C++/CLI is much faster even with /pure because the optimiser is significantly more advanced.

  • User profile image
    Sven Groot

    Ion Todirel wrote:
    
    JChung2006 wrote: I'm not sure why people think C# is faster than VB.NET.  Both compile to IL.
    C# has pointers. You can directly manipulate memory like in C/C++.

    It is quite a large fallacy to assume that the availability of pointers makes everything faster. Sure, it allows you to take some time saving shortcuts sometimes, but it also makes things that should be trivial incredibly difficult to optimize for a compiler.

  • User profile image
    stevo_

    I know both VB.net and C# well enough now to say I prefer C#, I spent over a year working solely in VB.net too, not that VB.net is a bad language, but working with a solution that has both VB.net and C# projects is a strange marriage..

    Firstly is that VB is generally 'looser' than C#, so theres some pretty slack standards that don't always apply well with C#, VB.net 'Optional' for arguments for example, presumably this would automatically create overloaded methods for you in IL (perhaps it even does), but as C# see's it, the optional param is a requirement, and doesn't have any overloads (unless you manually made some others).

  • User profile image
    Ion Todirel

    Sven Groot wrote:
    
    Ion Todirel wrote: 
    JChung2006 wrote: I'm not sure why people think C# is faster than VB.NET.  Both compile to IL.
    C# has pointers. You can directly manipulate memory like in C/C++.

    It is quite a large fallacy to assume that the availability of pointers makes everything faster. Sure, it allows you to take some time saving shortcuts sometimes, but it also makes things that should be trivial incredibly difficult to optimize for a compiler.
    I didn't say it makes everything faster, but it can sometimes improve performance, because you can alloc data on stack with stackalloc, that its not GC controlled.

  • User profile image
    phreaks

    Ok, I can appreciatte everyones comments.
    What I still am not understanding is why the VB.NET implementation of the exact same code executes faster?

    Let me also say that it only executes faster the first run through.

    When I first load NUnit and Run the Tests, the VB.NET time (Obtained from Diagnostics.StopWatch) is consistantly 2 Milliseconds.
    The C# Code is between 5 and 7 milliseconds.

    However, as long as I keep NUNit open and just rerun the tests, they both execute at 2 milliseconds. I am guessing that C# objects have more overhead and take longer to instantiate, but once they exist in memory, the actual execution time is the same?

  • User profile image
    Massif

    Or is the VB.NET compiler ngen-ing the output automatically somehow? In which case you're paying the price of the jitting for C# but not the VB code.

    I have no idea what settings would do this, but I have a vague feeling it's possible.

  • User profile image
    Massif

    Ion Todirel wrote:
    I didn't say it makes everything faster, but it can sometimes improve performance, because you can alloc data on stack with stackalloc, that its not GC controlled.


    But isn't memory allocation faster in .NET than in unmanaged programs? Isn't that possible because of the GC, so how would bypassing the GC improve performance?

    Genuinely curious here, not trying to stir anything up.

  • User profile image
    Ion Todirel

    GC costs

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.