PCL Tips and Tricks: String sbyte* constructor

The introduction of Portable Class Libraries, PCL, considerably facilitates the sharing of functionality across managed Microsoft and Xamarin platforms. I am very enthusiastic about the PCL concept, and I have ported several .NET Framework open source projects to Portable Class Libraries. Along the way I have stumbled across various issues of making .NET Framework source code PCL compliant. In this mini-series I'll share my experiences and workarounds to facilitate the transfer to PCL for other developers.

Some of the PCL profiles do support unsafe code, in particular those profiles targeting Windows 8 and Windows Phone 8.1 (non-Silverlight). This means that it is possible to include for example pointers in the PCL code. On the other hand, methods dealing with unsafe code are rare in the .NET Portable Subset.

One case I ran into the other day is the String constructor. In .NET Framework, there are a few constructors taking an sbyte pointer as an argument, for example:

public String(sbyte* value, int startIndex, int length)

This constructor is not available in the .NET Portable Subset, so I had to come up with a replacement. And I came up with this portable method:

static unsafe String NewString(
    sbyte* value, int startIndex, int length)
{
  var chars = new char[length];
  for (var i = 0; i < length; ++i)
    chars[i] = (char)value[startIndex + i];
  return new String(chars);
}

So, instead of calling new String(...), the calls were changed to NewString(...).

I am still not entirely pleased with this approach of adding a new method to solve the issue. If any blog reader has a leaner solution to this issue, I am all ears.

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.

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.