Get strong name token of .net binary from win32 environment

Question

5.00/5 (1 vote)

See more:

I have a c++ win32 console application (regsvr42) that generates manifest files and is compiled with /MT. Some of the dlls it adds to the manifest are .net and some are win32. All the dotnet ones are strong named. I need to get the public strong name token from the .net dlls so that I can reference them correctly in the manifest file.

sn -T mydllname.dll displays this token, but I need to get it from an api call that can be hooked into the win32 application. I can see that it can be done in the .net environment using reflection but I cann't us .net from my application /clr and /mt compile options are not compatable

Ideally I would like a way to get the token from win32 API simular to the way I can get the version information using GetFileVersionInfo

Posted 4-Jul-11 1:13am

ARopo

Add a Solution

Comments

Sergey Alexandrovich Kryukov 4-Jul-11 15:23pm

Interesting problem, my 5. I'm curious: what's the ultimate purpose of this activity? I hope my solution can work for you, please see.
--SA

ARopo 5-Jul-11 5:45am

Some background to this: We have a product which is a mix of win32 binaries and .net assembles. Many of the win32 modules use COM. Some .net modules are called through COM, and call some win32 modules through COM. Problem is we don't want a COM/Registry dependancy for deployment reasons, so we have to generate sidebyside manifest files and run the application COM free. We have 2 tools that generate the manifests Regsvr42 (win32 C++ console app) and GenMan (.net and deals with .net assemblies) The main exe is a win32 application so we use Regsvr42 to generate this manifest. In this generated manifest are listed all the dependancies of the exe some of which are strong named .net assemblies. Thus my question, regsvr42 is a win 32 console application written in C++ and compiled with /mt (so is incompatable with /clr i.e. cannot access .net)

Sergey Alexandrovich Kryukov 5-Jul-11 6:25am

I used to solve some related problem, it looks different, but the idea might be useful... I used COM as .NET was not there but I did not want to use Registry and any COM binaries from Microsoft. Reasons: 1) I hate involved "accidental complexity" and dependency on Registry, which is evil, 2) I needed COM inter-operation with Unix. I did it by implementing creation of the COM object without any MS binaries. We had one single exported function "CreateObject" which was used in all COM modules. In other words, from all COM I used only IDL + MIDL, code generation and binary layout for interfaces and implementation classes. It worked out wonderfully.
--SA

Sergey Alexandrovich Kryukov 4-Jul-11 20:00pm

Please see updated solution with added information on how to get a public key token of the assembly name (this is correct name for it).
--SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2011-07-04T09:22:00

First, I can see you're a bit confused about .NET part of getting version information. The method GetFileVersionInfo only gets file version. The versioning system of .NET software is usually based on assembly version, which is totally independent from the file version and is defined by the assembly attribute AssemblyVersion and the file version is defined by the assembly attribute AssemblyFileVersion.

Suppose you load an assembly from file. Here is how you get the version:

C#

System.Reflection.Assembly assembly = 
    System.Reflection.Assembly.LoadFrom(fileName);
System.Version version =
    assembly.GetName().Version;

Now, let's approach getting assembly by the Win32 unmanaged code. I suggest you work around the problem. First, create a .NET assembly which retrieve the System.Version information from the assemblies the way you want. It should clone this type into some managed type understandable by your unmanaged code.

Now, the problem is to deliver the result to the unmanaged code. You will need to create some static managed method in you library assembly and export it as unmanaged; and the unmanaged code should be able to load this library as a regular unmanaged DLL and call this method.

Many would say this is impossible. This is almost true but not all the truth. It is only impossible in C# or VB.NET, but quite possible using IL assembler; and this is a part of CLR ECMA and ISO standards, not like any dirty trick.

So, the idea is to use a special attribute to mark the methods to be exported as unmanaged. The code is complied by VB.NET or C#, disassembled; then the IL code is modified according to the attributes and assembled again. This is automated using the MSBuild custom step, so no knowledge of IL assembler is required.

You can find the solution in the following CodeProject articles:
Unmanaged code can wrap managed methods[^],
How to Automate Exporting .NET Function to Unmanaged Programs[^].

[EDIT]
Same approach goes for getting a public key token of assembly strong name. You can get it using your .NET library DLL. Use System.Reflection.Assembly.GetName().GetPublicKeyToken, see http://msdn.microsoft.com/en-us/library/system.reflection.assemblyname.aspx[^].

—SA