Getting product information from an unmanaged executable application in C # /. NET
In C # it is possible to get information related to an assembly like product name, version, etc. using reflection:
string productName = Assembly.GetCallingAssembly().GetName().Name;
string versionString = Assembly.GetCallingAssembly().GetName().Version.ToString();
How do I do the equivalent if the executing assembly is written in unmanaged C ++ (say)? Is it possible? Suppose I have a .NET dll that is called in unmanaged code through a COM interface.
edit
To be perfectly clear, this is my scenario:
- I have an executable written in unmanaged C ++
- I have a dll written in C # /. NET
- DLL is called executable via COM interface
- In a .NET dll I want to be able to retrieve information such as the product name and version of the invocation of the executable.
Possible?
source to share
Walking through the stack is not necessary to know which process you are in. You just make one Win32 API call:
HMODULE hEXE = GetModuleHandle(NULL);
As per the documentation for this call :
If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).
You can turn this module descriptor into a filename using GetModuleFileName () , another standard Win32 API. File name in hand, you can call GetFileVersionInfo () to retrieve the VS_VERSIONINFO structure for that file. The information you want is there.
Now that you are in .NET, you can use P / Invoke signatures for GetModuleHandle () , GetModuleFileName () . For GetFileVersionInfo (), you can use System.Diagnostics.FileVersionInfo .
But actually the easiest way to do this is probably to stick with the System.Diagnostics namespace, all you need is there. Call System.Diagnostics.Process.GetCurrentProcess () to return a Process object for the process you are working on. Then you can get the ProcessModule from the MainModule property . ProcessModule has a FileVersionInfo property . The information you want is there.
source to share
you can use the following code in VB.Net to get advanced document properties:
Sub Main()
Dim arrHeaders(41)
Dim shell As New Shell32.Shell
Dim objFolder As Shell32.Folder
objFolder = shell.NameSpace("C:\tmp\")
For i = 0 To 40
arrHeaders(i) = objFolder.GetDetailsOf(objFolder.Items, i)
Next
For Each strFileName In objfolder.Items
For i = 0 To 40
Console.WriteLine(i & vbTab & arrHeaders(i) & ": " & objFolder.GetDetailsOf(strFileName, i))
Next
Next
End Sub
Add a COM reference to Microsoft Shell Controls and Automation to compile your project.
The output of the above program will be a list of metadata assigned to all files in C: \ tmp, for example
0 Name: dpvoice.dll
1 Size: 208 KB
2 Type: Application Extension
3 Date Modified: 14.04.2008 04:41
4 Date Created: 14.04.2008 04:41
5 Date Accessed: 01.12.2008 09:56
6 Attributes: A
7 Status: Online
8 Owner: Administrators
9 Author:
10 Title:
11 Subject:
12 Category:
13 Pages:
14 Comments:
15 Copyright:
16 Artist:
17 Album Title:
18 Year:
19 Track Number:
20 Genre:
21 Duration:
22 Bit Rate:
23 Protected:
24 Camera Model:
25 Date Picture Taken:
26 Dimensions:
27 :
28 :
29 Episode Name:
30 Program Description:
31 :
32 Audio sample size:
33 Audio sample rate:
34 Channels:
35 Company: Microsoft Corporation
36 Description: Microsoft DirectPlay Voice
37 File Version: 5.3.2600.5512
38 Product Name: Microsoftr Windowsr Operating System
39 Product Version: 5.03.2600.5512
40 Keywords:
source to share
Suppose you are looking for EXE / DLL PE header data that @divo calls return, like Company, Product, etc. obtained from Win32 Version Info API call - details on MSDN:
The next difficulty you run into is listing the call stack to discover the context of your caller module. I haven't tried - but if you examine your own call stack, I doubt you will see unmanaged caller frames there. I suspect it stops at a transitional frame introduced before switching to CCW. Also, since this is COM, it's possible the caller can call from outside of the process - your caller will be a proxy process.
If that fails - you'll need a debug API to deploy the external stack - which introduces other restrictions:
- high security permissions required for stack traversal
- potential impact on performance unwinds the stack.
On the basis of invocation, any of these can make the debugger approach impractical.
Refresh
Some research shows that there are many bugs and errors to read the stack above the CCW transition frame even in the debugger. eg
Mixed unmanaged / managed character resolution is pretty ugly - some thoughts here on how to do it ... DaveBr's debugging blog is also pretty awesome.
There are many steps involved in sorting calls between unmanaged / managed clients
source to share