Decompiled DLL - Clues to help tell whether it was C# or VB.NET?

Question

When using something like DotPeek to decompile a DLL, how do I tell whether it was originally coded in VB.Net or C#?

I gather there's no easy way to tell, but that there may be tell-tale signs (ie. clues) in some of the decompiled code?

Answer 1

You can look for a reference to the Microsoft.VisualBasic library. If that is present, it's very probable that the code was made using VB. The library is sometimes included in C# projects also, but that is not very common. If the reference is not there, it's certainly not VB.

(Well, it's possible to compile VB without the library using the command line compiler and special compiler switches, but that is extremely rare.)

You can also check how frequently the VisualBasic library is used. In a regular VB program it would be used often, but in a C# program it would typically only be used for some specific task that isn't available in other libraries, like a DateDiff call.

Any VB specific commands, like CInt or Mid will show up as calls to the VisualBasic library, and even the = operator when used on strings, will use the library. This code (where a and b are strings):

If a = b Then

will actually make a library call to do the comparison, and shows up like this when decompiled as C#:

if (Operators.CompareString(a, b, false) == 0) {

Answer 2

One posible route might be to look for Named Indexers; It isn't allowed in C# i.e. you can only have the following in c#

object this [int index] {get;set;}

but in managed C++ and VB.Net (I believe, will delete this if I'm wrong) it appears you can have named indexers.

So at least you could narrow it down to whether or not it was C#

Answer 3

For completeness, I'll post the clue that I'm aware of:

If you decompile to C# and find invalid member names starting with $static$:

private short $STATIC$Report_Print$20211C1280B1$nHeight;

... that means it was probably VB.Net, because the compiler uses those to implement the 'Static' VB keyword.

Hans Passant and Jon Skeet explain it better over here: https://stackoverflow.com/a/7311567/22194 https://stackoverflow.com/a/7310497/22194

Answer 4

I'm surprised noone has mentioned the My namespace yet. It is very hard to get the VB.NET compiler to not include some of its helper classes in the output.

Answer 5

how do I tell whether it was originally coded in VB.Net or C#?

You can't tell that in a reliable manner. Well of course IL compiled with the VB.NET compiler will include references to some VB specific assemblies (such as Microsoft.VisualBasic), but there's nothing preventing a C# project also reference and use those assemblies.

Answer 6

To build on the ideas introduced in the other answers, the assembly does not report what language was used to write it, but you may look for non-cls compliant code

Being CLS compliant means that the code is written against features available to all CLS compliant languages. Which means that there are no public nested classes or named indexers and probably a number of other features that IL may support but any particular language may not.

If it is an option, you could probably just look at the PDBs.