Dig into the
System.Reflection.Assembly class. The
My namespaces and many other members are just shortcuts into that anyway. (That's actually an oversimplification;
Application.ProductName goes to great lengths to approximate a name if one doesn't exist, but we'll assume you're filling out your assembly metadata and don't have to worry about it like Microsoft did.)
The key difference between what they do and what your code wants to do comes down to picking which assembly to use. Here's the choices you have for getting an assembly:
- Assembly.GetCallingAssembly() gets the assembly that is calling the current method.
- Assembly.GetEntryAssembly() gets "the process executable in the default application domain".
- Assembly.GetExecutingAssembly() gets the assembly that contains the current line of code.
GetExecutingAssembly() is definitely the wrong one; it will always return the log manager's assembly.
GetCallingAssembly() could possibly work, but not if the log manager calls the code that fetches the assembly (documentation also points out optimization can mess this up.) That leaves
GetEntryAssembly(). I don't understand what the documentation means with confidence, but it sounds like it suggests it gets the assembly that has the entry point of the program that's running. More often than not that should be your application. Interestingly enough, this is the method that the MS code uses, so you might want to check with Microsoft's code before wasting time writing your own.
If it turns out
GetEntryAssembly() isn't reliable, you could have the application call
GetExecutingAssembly() and pass the result to your log manager; then the log manager would get the right assembly.
If you do have to write your own, once you get the right assembly it's just a matter of looking for the right information. Surprisingly enough the version, product name, etc. are attributes on the assembly. You may not know this because by default MS hides the file with the attributes; for the most part the philosophy has a patronizing "don't show VB developers something advanced or their head might explode" feel to it. In solution explorer, push the "Show all files" button and look for "AssemblyInfo.vb" under "My Project". Here's some (untested) code that (probably) gets the version:
Code:
Dim assem = Assembly.GetEntryAssembly()
Dim versionType As Type = GetType(AssemblyVersionAttribute)
Dim versionAttribute = CType(assem.GetCustomAttributes(versionType, False).First())
Dim version As String = versionAttribute.Version
Of course, you'll have to make sure your applications provide values for these attributes, but that's a decent practice anyway.