Looking at some analysis's online though would describe samples I would be tracking as VisualBasic as C# and vice versa. This was confusing with samples I was tracking as being copied from another variant as I expected them be the same source language.
I started looking at how VisualBasic and C# are compiled and if you could determine the source language of a .NET assembly. The following examples are simple 'Hello World' applications written in C# and VisualBasic.
With the exception of the string content we can see that the IL instruction set is identical in both the C# and VisualBasic assemblies.
- Dup - (Duplicate the value on the top of the stack.)
- Call SetProjectError
The setProjectError method is described as:
This API supports the .NET Framework infrastructure and is not intended to be used directly from your code.The Visual Basic compiler uses this helper method to capture exceptions in the Err object.
Looking for information on the setProjectError method I came across a post on the microsoft.public.dotnet.languages.vb list where Niklas from the complier team replied "The extra two calls are there to support the 'On Error' language feature which was retained to make it easier to upgrade from VB6 to VB.NET..."
This gives an indicator when looking at IL if it was generated using the VisualBasic compiler (vbc.exe). Within the catch clause the compiler will emit setProjectError and depending on the logic ClearProjectError. We don't see the second call in the example as the exception is thrown.
To test this I decompiled the VisualBasic compiled application and exported the IL as C#. Looking at the generated C# code there is the call to SetProjectError and a reference to Microsoft.VisualBasic.CompilerServices. If the source code was generated from IL compiled using the C# compiler, we would see 'throw exception;' with no reference to the SetProjectData method.
This class provides attributes that are applied to the standard module construct when it is emitted to Intermediate Language (IL). It is not intended to be called directly from your code.
VB.NET modules identical to a class with only shared members. When looking at emitted IL the module is compiled as a sealed class and that there is an additional reference to StandardModuleAttribute.
There are a number of other additional attributes which are generally specific to VisualBasic assemblies that can also be used as indicators such as the use of the My Feature and a number of other classes referenced within the CompilerServices Namespace.
Although these are specific to VisualBasic, C# applications could still reference functionality within VisualBasic namespaces. Obfuscation may also cloud the inclusion of these and isn't something I've looked into, but as they are references to the framework they should still be evident in samples.