After writing that blog post, I have received a number of suggestions and reactions from people from the #nixos freenode channel. Moreover, during the dinner of the SEAMS symposium in Hawaii, I have heard similar suggestions. It seems that blogging about certain issues pays off after all!
The last two days I have decided to look at these suggestions and to do some experiments at Philips. I'm happy to report that I have a follow up story now, in which I have a new solution for resolving run-time dependencies of .NET executables. This solution is also the best option (in my opinion).
Implementing a wrapper for .NET applications
Apparently .NET has a reflection API. With this reflection API you can dynamically load classes and dynamically invoke methods. You can also load assemblies dynamically from any location whether they have a strong name or not.
The .NET runtime also seems to fire an AssemblyResolve event, in case a library assembly can't be found. Apparently you can create your own event handler, dealing with such an event and use it to load a missing assembly through the reflection API.
So by taking these features into account, it is possible to create a wrapper executable capable of resolving the run-time dependencies that we need. This is what the wrapper I have developed for Nix looks like (I actually had to write some C# code for this):
using System;
using System.Reflection;
using System.IO;
namespace HelloWorldWrapper
{
class HelloWorldWrapper
{
private String[] AssemblySearchPaths = {
@"C:\cygwin\nix\store\23ga...-ALibrary",
@"C:\cygwin\nix\store\833p...-BLibrary"
};
private String ExePath =
@"C:\cygwin\nix\store\27f2...-Executable\Executable.exe";
private String MainClassName =
"SomeExecutable.Executable";
public HelloWorldWrapper(string[] args)
{
// Attach the resolve event handler to the AppDomain
// so that missing library assemblies will be searched
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.AssemblyResolve +=
new ResolveEventHandler(MyResolveEventHandler);
// Dynamically load the executable assembly
Assembly exeAssembly = Assembly.LoadFrom(ExePath);
// Lookup the main class
Type mainClass = exeAssembly.GetType(MainClassName);
// Lookup the main method
MethodInfo mainMethod = mainClass.GetMethod("Main");
// Invoke the main method
mainMethod.Invoke(this, new Object[] {args});
}
static void Main(string[] args)
{
new HelloWorldWrapper(args);
}
private Assembly MyResolveEventHandler(object sender,
ResolveEventArgs args)
{
// This handler is called only when the common language
// runtime tries to bind to the assembly and fails.
Assembly MyAssembly;
String assemblyPath = "";
String requestedAssemblyName =
args.Name.Substring(0, args.Name.IndexOf(","));
// Search for the right path of the library assembly
foreach (String curAssemblyPath in AssemblySearchPaths)
{
assemblyPath = curAssemblyPath + "/" +
requestedAssemblyName + ".dll";
if (File.Exists(assemblyPath))
break;
}
// Load the assembly from the specified path.
MyAssembly = Assembly.LoadFrom(assemblyPath);
// Return the loaded assembly.
return MyAssembly;
}
}
}
The wrapper class defined above has a number of fields. The AssemblySearchPaths field defines a String array containing all the Nix store paths of the runtime dependencies. The exePath field defines a String referring to the path of the executable in the Nix store which we want to run. The MainClassName field defines the full name of the class containing the Main method we want to run.
In the Main method of this class, we create an instance of the wrapper. In the constructor, we attach our own custom resolve event handler to the app domain controller. Then we use the reflection API to dynamically load the actual executable and to invoke the main method in the specified main class.
When we load the executable assembly, the resolve event handler is triggered a number of times. Our custom MyResolveEvent handler, tries to load to given assembly in all the search paths defined in the AssemblySearchPaths string array, which should succeed if all runtime dependencies are present.
There is a small caveat, however, with dynamically invoking the Main method of another executable. By default, the Main method in C# programs is defined like this:
namespace SomeNamespace
{
class SomeClass
{
static void Main(string[] args)
{
}
}
}
Apparently, it has no access modifier, which means the internal access modifier is used by default. The internal access modifier restricts access to this method to all members of the same assembly. This means that we cannot invoke an external Main method from a different assembly like the wrapper. To counter this, we need to make the access modifier of the actual executable public (or make the wrapper class a friend, but nonetheless we need to make a small modification anyway).
Usage
I have implemented a convenience function in Nixpkgs: dotnetenv.buildWrapper that automatically builds a .NET executable and generates a wrapper for the given executable. The function can be invoked like this:
{dotnetenv, MyAssembly1, MyAssembly2}:
dotnetenv.buildWrapper {
name = "My.Test.Assembly";
src = /path/to/source/code;
slnFile = "Assembly.sln";
assemblyInputs = [
dotnetenv.assembly20Path
MyAssembly1
MyAssembly2
];
namespace = "TestNamespace";
mainClassName = "MyTestApplication";
mainClassFile = "MyTestApplication.cs";
}
As you may see, the structure of the dotnetenv.buildWrapper is similar to the dotnetenv.buildSolution function, except that it requires several additional parameters for the wrapper, such as the namespace, class name and file location of the class containing the Main method of the actual executable. The function automatically makes the given Main method in the given main class file public and it creates a wrapper class containing the right properties to run the actual executable, such as the location of the actual executable and the paths of the run-time dependencies.
By using this wrapper function, it is possible to run a .NET executable assembly from the Nix store without much trouble.
Conclusion
In this blog post, I have implemented a wrapper executable that deals with resolving run-time dependencies of a .NET application. The wrapper uses a resolve event handler which loads all the required library assemblies through the .NET reflection API. This wrapper can be automatically generated from a convenience function, which makes it possible to run .NET applications from the Nix store, without much trouble.
References
- This page explains how the reflection API can be used to dynamically load assemblies: http://www.codeproject.com/KB/cs/DynLoadClassInvokeMethod.aspx
- The following page explains various ways to load library assemblies beyond the base directory of the executable. It also includes an explanation of the AssemblyResolve event: http://support.microsoft.com/kb/837908
No comments:
Post a Comment