How to make Silverlight version of existing C# code that relies on System.Drawing namespace

We have pretty much C# 2.0 code that heavily relies on System.Drawing namespace. Also there is some WinGDI dependencies (via interop).

How would you recommend to tackle the problem of making functionally equivalent Silverlight version of the code? We want to reuse code as much as possible because we want to continue develop both versions of the code.

Maybe there is some articles/books you could recommend?

UPDATE: The code is a non-visual component. Not an application. There is no 3rd party dependencies.

Solution

First of all, you should accept that some of the features of the original code won't make it to Silverlight version. Interop, reading and writing files - such things are either forbidden because of security reasons or just unsupported.

Second thing to have in mind is that your code will be polluted with conditional compilation (in case you want to continue to support building of .NET version from the same code base).

And the third thing is - you will have to write some new code (instead of removed code). For example, you might need to create new methods that accept WriteableBitmap instead of methods that accept System.Drawing.Bitmap in order to give users of Silverlight version similar set of features.

Ok, let's take a look at what you might need to do in order to create Silverlight version of a .NET library.

Create new project for Silverlight version
Add all existing code files to this project as links.
Try to build the project. Most probably the build will fail with many warning and error messages. Obviously, the goal is to fix all of them.

Here is some hints for what can be done to fix common build errors.

Remove all using namespace-name directives that are not needed. Exclude unsupported namespaces with conditional compilation like so:

#if !SILVERLIGHT
    using System.Drawing;
#endif

If you are using enumerations that are missing in Silverlight (e.g. System.Drawing.Imaging.ImageFormat) then introduce equvalent custom enumerations (e.g. MyImageFormat) and change internal code to use only custom enumerations. Add overloaded methods that use custom enumerations (or equivalent Silverlight enumerations) to public interface, if needed.
Do likewise for the structs (e.g. System.Drawing.PointF) or change the code to use simpler types (e.g. two floats instead of PointF structure)
Exclude public and private code that uses unsupported structures with conditional compilation. Consider rewriting internal code so it will use only language constructs supported in .NET and Silverlight.
Create a wrapper class for accessing embedded resources in Silverlight version because there won't be any ready-made wrappers that give you byte[] or string for binary and text resources.
Create a property like this

    public static Encoding DefaultEncoding
    {
        get
        {
    #if SILVERLIGHT
            return Encoding.UTF8;
    #else
            return Encoding.Default;
    #endif
        }
    }

And use this property instead of Encoding.Default in your code.

Sooner or later you will be able to create Silverlight version of your code. This version will probably have less features but, hey, Silverlight is not a full-blown .NET. Some features will even be unnecessary in Silverlight. For some original features you might later add equivalent ones.

If you are using nunit for unit-testing your .NET version then you might want to take a look at nunit-silverlight (check this page too) for testing Silverlight version. There are some caveats, though.

TestCaseSource attribute is unsupported by nunit-silverlight.
Reading of local files is unsupported.

If you need to read or write local files in your tests then you should use Silverlight 4 for your test application. There is no way to do this in Silverlight 3. You should also setup your test application as Out-of-Browser one and give it elevated trust rights (check "require elevated trust" in Out-of-Browser settings)

You'll need a wrapper (yeah, another one) for reading and writing local files, because Silverlight tests will be able to consume and produce only byte buffers and streams.

Here are some code snippets that might be useful for the wrapper:

Get the path to current folder:

Uri uri = new Uri(System.Windows.Application.Current.Host.Source, relativeFileName);
var currentPath = uri.OriginalString;

Please note, that you'll need to remove file:// from the beginning of currentPath

Reading local files (via COM Automation)

private static byte[] readBinaryFile(string fileName)
{
    const int adTypeBinary = 1;

    using (dynamic adoCom = System.Runtime.InteropServices.Automation.AutomationFactory.CreateObject(@"ADODB.Stream"))
    {
        adoCom.Type = adTypeBinary;
        adoCom.Open();
        adoCom.LoadFromFile(fileName);

        return adoCom.Read();
    }
}

Writing local files (also via COM Automation)

private static void writeBinaryFile(string fileName, byte[] binaryArray)
{
    const int adTypeBinary = 1;
    const int adSaveCreateOverWrite = 2;
    using (dynamic adoCom = System.Runtime.InteropServices.Automation.AutomationFactory.CreateObject(@"ADODB.Stream"))
    {
        adoCom.Type = adTypeBinary;
        adoCom.Open();
        adoCom.Write(binaryArray);
        adoCom.SaveToFile(fileName, adSaveCreateOverWrite);
    }
}

You may also want to check Silverlight COM Toolkit. I don't use it, though.

Good luck!