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

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

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.

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

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

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

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 

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.

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

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 ( ohh I kid)

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.

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.

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

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?

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.

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.