How to sign C++ assemblies with a strong name

21 10 2012

Strong Name (SN) is a technology introduced with the .NET platform, which gives a globally unique identity to the applications or components. If our application is signed with a strong name, then it is mandatory to sign all assemblies it refer.

In case if you are working in COM dll or Managed C++ library, you may need to provide signed version of your DLL to client applications.

First step is to create a key file using sn.exe tool which we can find out with .NET Framework SDK,

sn.exe -k [Directory]\MyKey.snk

Sign COM Interop DLLs

If we are working on COM dlls, generally we generate ineterop DLLs too for .NET client applications. This can be generated by tlbimp.exe.
Tlbimp.exe provides the functionality to set a /keyfile: as an argument to generate the interop dll which is signed with a Strong Name.

The following commands shall be added to the project’s post build events.

tlbexp MyComDll.dll /out:MyComDll.tlb
tlbimp MyComDll.tlb /keyfile:MyKey.snk /namespace:Company.MyComDll /output:Interop.MyComDll.dll

Sign Managed C++ library

A managed DLL can be signed by specifying the key file in visual studio project settings at Project-> Properties-> Configuration Properties-> Linker-> Advanced-> Key File

We can check whether our DLLs are signed or not using same SN.EXE tool. The following command will give key information.

sn.exe -T MySignedDll.dll

what is the use of AFX_MANAGE_STATE?

15 01 2009




We are familiar with Dynamic Link Libraries (DLLs) and most of our daily application development activities are using it. If you have an exported function in DLL and you don’t use any resources from the DLL itself  then you could invoke it from an executable module and it will work fine. 🙂

But you want to launch a dialog from the DLL module and which is from it’s own resource part. What will happen if you invoke the domodal of a dialog from any of the exported function in the DLL. No doubt, the domodal will return -1. 😦




Actually what is happening here, once we try yo launch a dialog from the DLL from its own resource – but the application holds the resource handle of the main application. So we need to switch the module state for the correct handle to be used. We can do this by adding the following code to the beginning of the exported function in the DLL,

AFX_MANAGE_STATE( AfxGetStaticModuleState() );

This swaps the current module state with  the state returned from AfxGetStaticModuleState( ) until the end of the current scope. This is a macro used to protect an exported function in a DLL.




Regular DLL exported function

extern "C"
void _declspec(dllexport) MyExportedFunction(void)
   AFX_MANAGE_STATE( AfxGetStaticModuleState() );
   CMyCustomDialog MyCustomDlg;
   if( -1 == MyCustomDlg.DoModal() )

Main application function

typedef void (CALLBACK* LPFUNPOINT)(void);

void LoadDLLFunction()
   //Load your dll from the path
   HMODULE hm = LoadLibrary("D:\\SAN\\RegularDll\\Debug\\RegularDll.dll");
   LPFUNPOINT   lpProc;
   if(NULL != hm)
      lpProc = (LPFUNPOINT)GetProcAddress(hm, _T("MyExportedFunction") );
      if(NULL != lpProc)




That’s working fine in the Regular DLL, now if we try the same routine with the MFC Extension DLL it may lead to a link error like this,

mfcs42d.lib(dllmodul.obj) : error LNK2005: __pRawDllMain already defined in ExtensionDLL.obj

How can we remove this. Please follow the link MIcrosoft: Help and Support.