Friday, September 16, 2011

P/Invoke: Bundling native DLL:s in Silverlight 5 RC applications

One of the many interesting new features in Silverlight 5 RC is the ability for elevated trust applications (in-browser as well as out-of-browser) to access native DLL:s via P/Invoke.

Some interesting application examples are given here and here. These examples show how easy it is to access system DLL:s such as user32.dll, kernel32.dll and psapi.dll. However, the issue appears to be more complex when it comes to native DLL:s that are not automatically available on the system.

Ideally (I think), you would like to bundle the native third party DLL:s as Content in the XAP file, and the XAP file would be artificially included in the P/Invoke search path. Unfortunately, this is not the way it works today. When I bundle my third-party native DLL as Content in my Silverlight 5 RC application, and try to access one of its methods via the following declaration,

[DllImport("NativeDll")]
public static extern int add(int a, int b);


I get a discouraging DllNotFoundException. It does not help if I add the .dll extension to the file name, and I have also not been able to find the DLL by applying any of the pack URI approaches to the DLL file name.

Several people, including myself, have brought up this issue in various forums, but so far I have not seen any published solution to the problem.

Well, as we say in Sweden, "själv är bäste dräng" (which is similar to "if you want something done, do it yourself"), so here is my attempt to solve the problem. Granted, it might not be the most Elegant Solution, but at least it is A Solution.

It is important to note that this solution is applicable primarily to Silverlight 5 RC. In the best of worlds, Microsoft will fix the native DLL path issue in the RTM release of Silverlight 5, and then this solution would be superfluous. We'll see what happens in the end.

Note also that since P/Invoke is a feature requiring elevated trust, this solution is only relevant to applications running in elevated trust (in- or out-of-browser).


In short, the solution is to bundle the native third party DLL:s as resource files in the Silverlight 5 RC application, and when the application is started copy these DLL:s to a local directory and add the directory to the system path during the execution of the Silverlight application.

In more details, here is how it can be done:

Add each native third party DLL as an existing item to the root folder or, even more preferably, to an assets sub-folder in the Silverlight 5 RC application project.


In the File Properties window, set Build Action to Resource and Copy to Output Directory to Copy if newer.


The DLL copying and PATH environment variable setting of course requires some additional code. Fortunately :-) I have created a static utility class for this purpose. The class is named NativeDllHelper and can be found it is entirety here. Download and add this file to your Silverlight 5 RC application project.

Next, go to the App.xaml.cs or equivalent file. Add the following using statement.

using Cureos.Utility;

In the Application_Startup (or equivalent) event handler, add the following method call to the first line of the event handler.

NativeDllHelper.SetupNativeDllFolder("relpath/dllname.dll", ...);

where relpath is the path relative to the project root folder where the native DLL:s are located, and dllname is the file name of the DLL. Specify all DLL:s to be copied in one argument list; the SetupNativeDllFolder method should only be called once at start-up to avoid adding duplicate entries of the local DLL directory to the system path.

The native DLL files are copied to a My Documents sub-folder Silverlight\Native. If you prefer a different folder for the DLL:s, edit the static constructor of the NativeDllHelper class.

Here is an example call of SetupNativeDllFolder, copying one file NativeDll.dll located in the Assets sub-folder of the Silverlight 5 RC application project.

NativeDllHelper.SetupNativeDllFolder("Assets/NativeDll.dll");

Having performed these steps, no user intervention is required when running the application, the native methods in the third party DLL:s can simply be invoked using only the file name of the DLL:

[DllImport("NativeDll")]
public static extern int add(int a, int b);


A complete example SL 5 RC application utilizing this functionality can be downloaded from here. Note that it contains a C(++) project for creating the example native DLL.
If you try out the application and get build errors due to copy prevention the first time, building a second time should do the trick. You might also need to manually set the start page of the Web project to the .aspx file.


The application itself is very simple; there is this button

with the following click event handler associated to it:

private void Button_Click(object sender, RoutedEventArgs e)
{
  button.Content = add(5, 7);
}

The add method is a native method, as declared above. Clicking the button leaves us with the following satisfying button update:

And that is basically all that there is to it. The utility method for copying DLL:s from the application resources can most certainly be further improved, for example by more efficiently handling DLL:s already existing locally. With the current implementation, any existing DLL:s are automatically overwritten. All improvement suggestions as well as reports of successes or failures are highly appreciated.

Monday, September 5, 2011

csipopt on Silverlight: almost there!

As mentioned in a recent post, it is possible to enable unsafe code support in the release candidate of Silverlight 5 for out-of-browser (OOB) applications in elevated-trust mode. Together with the introduction of P/Invoke support in Silverlight 5, it would thereby in principle be possible to also use my csipopt .NET interface to the IPOPT optimizer in Silverlight.

I have now tested to build and run csipopt on Silverlight 5 RC, and it almost works:
  • The code successfully builds, provided the <AllowUnsafeBlocks> tag is manually set to true in the .csproj file.
  • If I bundle the native IPOPT DLL:s as content or resources in the XAP file, I get a DllNotFoundException. At this point I do not know if this is a bug or by design. For now, it works to place the native IPOPT DLL:s in a directory that is included in the system path.
  • When I run my csipopt calling application in OOB elevated-trust mode, I eventually get a SecurityException: An error relating to security occurred
The exception occurs when trying to access an UnmanagedFunctionPointerAttribute in a call to an imported function from the native DLL. It remains to find out whether this restriction will persist into the final release of Silverlight 5. According to the API documentation, the UnmanagedFunctionPointerAttribute is not intended for regular user code in Silverlight. This writing might not be entirely up-to-date, but realistically, I think the restriction will be there at least in Silverlight 5. After all, I am pushing the limits here, using P/Invoke and unsafe code at the same time.

So, bets are I have to wait for Silverlight 6 to employ csipopt in my Silverlight applications.

DICOM on the phone!

I received an e-mail the other day from Pantelis Georgiadis. He wrote that he had forked my mdcm fork and that he is now developing a Windows Phone 7.1 ("Mango") class library based on my Silverlight mdcm efforts.

It is really great to see that Colby Dillion's, and more recently my, work on this C# DICOM library is now proliferating into the phone. It will be very interesting to follow Pantelis's work and see what kind of applications will come out of his efforts.

Friday, September 2, 2011

Unsafe support in Silverlight 5?

Silverlight 5 Release Candidate is available for download since yesterday. Interestingly enough, the RC supports P/Invoke for calling native functions. If only Silverlight could also support unsafe code, it would maybe be possible to use csipopt, my .NET interface to the IPOPT optimizer, from Silverlight...

After downloading and installing the Silverlight 5 RC Tools for VS 2010 SP1, I created a simple Silverlight 5 application project. Discouragingly, the Unsafe checkbox in the project settings is still disabled:


But at least the checkbox is there... Maybe I can manually edit the project file. In a regular C# project, unsafe support is indicated within each configuration/platform PropertyGroup using the following tag:

    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>

So, let's insert the same specification in the Silverlight project file and reload the project. The unsafe checkbox is still disabled, but lo and behold, the checkbox is checked!


Next, let's see if I can add some unsafe code and build it. First, I create a button with the instructive text "Click me!". I add the following event handler for the button Click event:

unsafe private void UnsafeTestButton_Click(
    object sender, RoutedEventArgs e)
{
    int i = 5;
    SquarePtrParam(&i);
    UnsafeTestButton.Content = i;
}


The event handler in turn calls a simple unsafe method that dereferences an integer pointer and squares it:

unsafe static void SquarePtrParam(int* p)
{
    *p *= *p;
}


After calling the SquarePtrParam method, the click event handler should update the button content to the value of the squared integer. (If the code looks familiar I have copied it from MSDN:s C# reference section on unsafe.)

When I now build this "unsafe" Silverlight application, I get the encouraging prompt "Rebuild All succeeeded"!

Next question is, can the "unsafe" Silverlight application also be executed? It turns out that when I run it in-browser and click the button, I encounter a VerificationException, "Operation could destabilize the runtime", regardless of whether I run in normal or elevated trust. When I run out-of-browser, I get the same exception when running in normal trust, but when running out-of-browser and elevated trust, I can successfully go from here:

to here:


So the conclusion is that Silverlight 5 RC does provide hidden-away support for unsafe code. At this point it only seems to be executable out-of-browser in elevated trust. It will be interesting to see to what extent the unsafe support will be exposed in the official Silverlight 5 release.

Sidenote: I was also able to build the "unsafe" project with Silverlight 4. However, in this case I encountered the VerificationException in out-of-browser elevated-trust mode as well.