Saturday, 16 February 2008

Silverlight and Code Reuse with non Silverlight applications

One of the problems we face with Silverlight is that Silverlight Projects can only reference Silverlight Class libraries, and other types of projects (such as WPF) cannot reference those Silverlight class libraries.

For example if I have a common static class has one static method that returns hello world.

namespace MyCrossCode
public static class Common
/// <summary>
/// Returns Hello World
/// </summary>
/// <returns></returns>
public static string HelloWorld()
return "Hello World";

Then its logical that i would want to be able to share that class in 2 different versions of my application without code duplication.

With the current referencing model it leaves us in an awkward situation as we want to be able to resuse common code if possible in both applications without having to maintain two versions of the code.

I suggest one solution for Microsoft would be to provide us the ability in Visual Studio to be able to add code compliant with both the targetted version of the .NET Framework and with Silverlight. Compilation would produce us two versions of the assembly and the Silverlight version is automatically included in our Silverlight apps and the non Silverlight version for our Windows versions of our applications.

One way this could be achieved is the using a concept of Virtual Assembly reference, so rather than referencing the assembly directly, we reference a virtual assembly. So if its a Silverlight Application it will use the Silverlight version of the assembly, and if its non Silverlight it will use the non Silverlight version. The key thing about compliant projects is that non cross compatible code will fail to compile.

Anyways, I hope Microsoft looks at implementing this solution (or another solution) to this problem (especially in the Silverlight 2.0 timeframe).


koen said...

I like your Virtual Assembly suggestion, but there are a lot of other issues to resolve;

* A class that exists in one platform and not in another. you probably want to solve this with compiler directives (#ifdef SILVERLIGHT, etc.)
* A nightmare; a class that behaves differently on two platforms. Take the Point struct for example. In .NET it's using integers for X and Y in Silverlight doubles are used.
* .. and more (i'm sure).

Code reuse among different .NET platforms is going to be debated a lot in the near future I reckon.


chrishayuk said...


I agree there are lots of other issues to consider (especialy the ones you mention), however i think that through visual studio and the cross compatible project (which uses the virtual assembly reference), you could provide warnings/errors on compilation about usage of certain classes. So for example the Point struct, it would generate either an error or warning about the difference.

The second solution to this sort of problem is provide implementations that do match within the .NET Framework / Silverlight. For example Point could become Point2 and if you want to be cross compatible you should now use point 2.

I'm glad you like the Virtual Assembly suggestion, I am sure there are loads of other ideas to solve this problem, but I think it is important to highlight the issue as a lot of people are going to hit these very issues, very very soon.

Daniel Moth said...

I would be very surprised if there was any clever tool support for this when there was no clever tool support for the exact same issue between NETCF and full NetFx.

Manually setting up the two projects and reusing code files via conditional compilation is the answer. See my MSDN mag article that describes this for mobile<->desktop and apply the same principles for SL<->wpf.

I will write more about this in the mid-term (specifically in the context of SL 2.0)...

chrishayuk said...

Thanks Daniel.

This is the link to daniels article, it's a great little technique for code reuse (from the world of compact framework who already have these issues).

I understand what Daniel is saying and I like his techique and awful lot.

My only concern is that you still manually have to maintain two versions of the same assembly (although it is only linking code), it is still requires overhead, hence why i still think tool support is the real answer.

If you don't mind Daniel I would love folks to know about this technique as soon as possible, so i might extract the key parts of your article and give big links and quotes from it, so people have a method of reuse already.

I do however look forward to your Silverlight specific version.

Thanks for the workaround, Daniel most appreciated! However as I said I would still prefer to see proper support in Visual Studio for these scenarios.