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.

---

I have a great experience in creating wpf/silverlight versions of software that used to be built using winforms. It's sad, but in your case, when you use a lot of interop and System.Drawing things, it's practically impossible to do such a thing.

Of cource, you can always try (and really you always have to) to separate your business logic from interface, but in such situation (I hope a'm wrong!), your interface have to be completely redesigned, because of differences in architecture of winforms and wpf/silverlight.

In my experience, this problem solved in this way: all old winforms components stayed just the same, but all new features were built using wpf with help of injection of wpf controls into winforms application.

Yes, sometimes it's weird, but it's really more productive than just waste all your old code and spend huge amount of time and money into new, that does just the same.

---

If there is no GUI and you are still using lots of System.Drawing I guess what this component does is related to manipualtion of images in memory.

If that's the case, due to the very high cost of porting all the code, if at all possible, you can consider to change your architecture.

Have the old code in the server side, where you can freely use these APIs, and expose the required functionality to your Silverlight application through some web service. If the component has no GUI it should be very feasible.

Edit: Adding suggestions of how this might be appropriate for developers

Maybe this might still work - if your developer plans to deploy this Silverlight control in a web page, then he probably has a web server on which he can place your component to be accessible for the Silverlight code.

If the developer plans to deploy your Silverlight code in Out-of-Browser mode, you can make a version that would embed the old component (for example as a COM object).

An addition alternative to the above, would be to host this component yourself on a server, or on some public cloud such as Windows Azure.

---

This is going to be near impossible as both WPF and Silverlight are fundamentally different than older versions of this. If you really want to be able to develop a desktop and web applications at the same time, you would probably be better off using WPF and Silverlight.

Only problem this is reusing code is still difficult because Silverlight doesn't have all of the features that WPF does. On top of all of this, the model for accessing data in Silverlight is totally asynchronous.

You would be best off building the application in Silverlight, and then porting that application to WPF.

Probably not the answer you were looking for.

---

Depending on how your existing code base is architected this may not be possible, but you can load Forms controls inside of WPF see this example. If your legacy code is packaged into controls, you may be able to get a lot of code re-use. I hope this helps.

---

Here's another wild idea.

Isolate all your System.Drawing, PInvoke, GDI, etc. into a separate component, and wrap it as an ActiveX object.

Embed the ActiveX object in your web page, and make your Silverlight application consume its services somehow. I guess this would require some "plumbing" in the level of the web page (e.g. a script that would activate the ActiveX object, and expose the results to the Silverlight app through the document or something)

This is just an initial thought I had. I guess it can be improved in many ways. What do you think? :)

Edit: If it is acceptable for your Silverlight code to run in Out-of-Browser mode, then Silverlight 4 supports embedding an ActiveX control in your Silverlight application. This just might make it feasible to wrap all your old implementation in some ActiveX and use it from Silverlight.

---

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.

1. Create new project for Silverlight version
2. Add all existing code files to this project as links.
3. 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.

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

#if !SILVERLIGHT
    using System.Drawing;
#endif

1. 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.

2. 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)

3. 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.

4. 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.

5. 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.

1. TestCaseSource attribute is unsupported by nunit-silverlight.
2. 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!