Recupero delle informazioni sul prodotto da un'applicazione in esecuzione non gestita in C # /. NET

Question

In C #, è possibile recuperare informazioni relative all'assemblaggio come nome del prodotto, versione ecc. utilizzando reflection:

string productName = Assembly.GetCallingAssembly().GetName().Name;
string versionString = Assembly.GetCallingAssembly().GetName().Version.ToString();

Come posso fare l'equivalente se l'assembly in esecuzione è scritto in C ++ non gestito (diciamo)? È anche possibile? Supponiamo che io abbia una DLL .NET che viene invocata in codice non gestito tramite un'interfaccia COM.

modifica
Per chiarire le cose, questo è il mio scenario:

• Ho un eseguibile scritto in C ++ non gestito
• Ho scritto una dll in C # /. NET
• La dll è invocata da eseguibile tramite un'interfaccia COM
• All'interno della dll .NET voglio essere in grado di recuperare informazioni come il nome del prodotto e la versione di chiamando eseguibile.

Possibile?

Answer 1

Camminare in pila non è necessario per scoprire in quale processo ci si trova. È sufficiente effettuare una singola chiamata API Win32:

HMODULE hEXE = GetModuleHandle(NULL);

Secondo la per questa chiamata :

  

Se questo parametro è NULL, GetModuleHandle restituisce un handle al file utilizzato per creare il processo chiamante (file .exe).

Puoi trasformare questo handle del modulo in un nome file con GetModuleFileName () , un'altra API Win32 standard. Nome del file in mano, puoi quindi chiamare GetFileVersionInfo () per recuperare la struttura VS_VERSIONINFO per quel file. Le informazioni desiderate sono lì.

Ora che sei in .NET potresti usare le firme P / Invoke per GetModuleHandle () , GetModuleFileName () . Per GetFileVersionInfo () è possibile utilizzare System.Diagnostics.FileVersionInfo .

Ma in realtà il modo più semplice per farlo è probabilmente attenersi allo spazio dei nomi System.Diagnostics, tutto ciò che serve è lì. Chiama System.Diagnostics.Process.GetCurrentProcess () per restituire un oggetto Process per il processo in esecuzione. Quindi è possibile recuperare un ProcessModule dal proprietà MainModule . ProcessModule ha una proprietà chiamata FileVersionInfo . Le informazioni che desideri sono lì.

Answer 2

è possibile utilizzare il seguente codice in VB.Net per recuperare le proprietà estese del documento:

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

Aggiungi un riferimento COM a Microsoft Shell Controls and Automation al tuo progetto da compilare.

L'output del programma sopra sarà un elenco dei metadati assegnati a tutti i file in C: \ tmp come

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:

Answer 3

Supponiamo che tu stia cercando dati di intestazione PE di una EXE / DLL restituiti dalle chiamate di @ divo, ad es. Azienda, Prodotto ecc ... Questi a proposito. derivano dal richiamo delle API di informazioni sulla versione di Win32 - dettagli su MSDN:

  

http://msdn.microsoft.com/en-us/library /ms646981.aspx

La prossima sfida che dovrai affrontare è enumerare il callstack per scoprire il contesto del modulo del tuo chiamante. Non ci ho provato - ma se esamini il tuo callstack, dubito che vedrai i frame del chiamante non gestito schierati lì dentro. Si sospetta che si arresti al frame di transizione iniettato prima di passare al CCW. Inoltre, dato che si tratta di COM, è possibile che il chiamante possa chiamare da fuori processo: il chiamante sarebbe un processo proxy.

Se fallisce - avresti bisogno delle API di debug per srotolare lo stack esterno - che introduce altri vincoli:

• autorizzazioni di sicurezza elevate richieste per attraversare lo stack
• potenziale impatto sulle prestazioni svolgendo lo stack.

Su una di queste chiamate uno di questi potrebbe rendere impraticabile l'approccio al debugger.

Aggiorna

Alcune ricerche indicano che ci sono molti bug e trucchi per leggere lo stack sopra il frame di transizione CCW anche nel debugger. per esempio.

  

http://support.microsoft.com/kb/317221

La risoluzione mista di simboli non gestiti / gestiti è piuttosto brutta - alcuni pensieri qui su come farlo ... Anche il blog di DaveBr sul debug è abbastanza fantastico.

  

http : //bytes.com/groups/net-vc/280340-stackwalk-callstack-symbol-resolve-managed-unmanaged-code-dbghelp-etc

     

http://blogs.msdn.com/davbr/archive/2005/10/06/478006.aspx

Esiste un sacco di foraggio sui passaggi effettuati per il marshalling delle chiamate tra client non gestiti / gestiti, ad es.

  

http://msdn.microsoft.com/en-us/library /ms973872.aspx