Hosting Common Language Runtime in Unmanaged Codes without the Dependency on .NET Framework

Hosting Common Language Runtime in Unmanaged Codes without the Dependency on .NET Framework

Introduction

The Hosting APIs of Common Language Runtime (CLR) provide an easy way to dynamically launch an application written in managed code in the unmanaged world. The topic has been well discussed and is out of the scope of this article.

This article will talk about an issue that you will face when using CLRs Hosting APIs. Suppose you want to write an EXE launcher that can launch executables written in managed and unmanaged codes. It is expected that the launcher can run without the .NET Framework if it does not launch any managed codes; the .NET Framework is required only when trying to launch a managed application.

The commonly used method to host CLR in an unmanaged program is to call CorBindToRuntimeEx. However, in doing so, you will quickly find out the problem that your application cannot work without mscoree.dll, an unexpected dependency on the .NET Framework.

The cause of the issue is that CorBindToRuntimeEx is exported from mscoree.dll. It will link to mscoree.dll at runtime. To resolve the dependency issue, we must avoid any functions provided by mscoree.dll.

The purpose of calling CorBindToRuntimeEx is to create an instance of the ICorRuntimeHost interface pointer. So we use CoCreateInstance to create an ICorRuntimeHost instance instead of using CorBindToRuntimeEx.

Comments and Discussions

considering thay most operating system(Windows O/S) comes with built the dot net framework, i see little need for running unmanage codes without the need for the dot net framework unless there is a comparative advantage to using these.
Is there some comparative advantage?
On the other hand, I have the feeling that these will be much slower.

Thank you so much! To clarify, when I use #pragma comment(lib,"mscoree.lib"), or Linker->Input->Additional Dependencies: mscoree.lib. The lib still depend/require on mscoree.dll at runtime for it's functions?

To encrypt the managed code and execute it with custom CLR host is a good idea. But who will guarantee that CLRHost->Start() cannot be hooked and by this way the cracker can get the decrypted managed code in the moment before it is sent to CLR?