views:

94

answers:

3

Dear ladies and sirs.

We have some .NET client side code, which we would like to port to Silverlight. However, the current .NET code simply does not compile on the Silverlight platform. Along with some subtle issues, there are many simple issues, like: - some exceptions have less constructors in SL - Debug.Fail does not exist in SL - BindingList does not exist in SL - severe limitations are placed on private reflection etc...

Some of these differences can be applied to the plain .NET code, in order to minimize the differences between the .NET and SL code base. Like I do not mind to call Debug.Assert with false instead of Debug.Fail in my .NET code if it makes the code less polluted with #if SILVERLIGHT. The same is true about replacing BindingList with ObservableCollection.

My question is there a tool which given a .NET assembly can present some kind of Silverlight compatibility report, which would indicate the changes that must be made to the .NET code base in order to bring it as close as possible to the Silverlight platform?

Thanks.

EDIT:

The tool does slightly more complex job that just compiling the code in SL and presenting the errors. This has to do with code present in SL and .NET, but in SL it is unavailable to the regular (transparent) code. Invoking it would result in an exception on SL.

EDIT 2:

A few words of further clarifications are due:

  1. The code is not a UI code. It is neither WinForms, nor WebForms nor WPF. It is pure business logic code upon which the client side UI depends.
  2. We base our business logic on the Lhotka's CSLA library, which does have an SL port.
  3. Using VS to compile the project in SL only reports the compilation errors. It will not notify me of any invalid API usages, like invoking a method which is SecurityCritical in SL.
A: 

This is not the answer you will be wanting to hear, but what is wrong with using Visual Studio - it tells you where the errors are when you try to compile.

If you are looking for a report so that you can scope how long some work will take, then a report is not going to tell you that with any accuracy. It isn't just the fact you are operating with a cut down version of the framework, things are also done considerably differently in Silverlight, for instance WinForms cannot be directly translated and even WebForms will need a reasonable amount of work to become a Silverlight page/form.

slugster
Thanks for the reply. I have clarified my question.
mark
A: 

I would suggest you split your code into multiple tiers, then you can replace the UI tier without rewriting the lower tiers.

Sheng Jiang 蒋晟
Thanks for the reply. I have clarified my question.
mark
+1  A: 

You do realise that your business logic does not have to be Silverlight compliant? Why don't you just expose your business logic through some webservices (which is a relatively trivial task), and call it from the Silverlight code? The Silverlight code and webservices can even reside on the same machine and each uses their own version of the framework, you don't have to host the webservices on a different machine. Doing things this way means you can code up a nice thin Silverlight UI, and do minimal work on the business layer.

(this answer supercedes my previous one and is in response to the clarified question)

slugster
Interesting. But I doubt it would work. As I see it, a rich desktop client must rely upon quite sophisticated business layer. The interaction between the UI and the client side business layer is quite intensive. I am not sure that the application is going to be very responsive if the two are in different processes talking Web Services. But it is interesting and I wonder if anyone has taken such an approach and has anything to share. Have you?
mark
You are right in the fact that web services do slow things down, but only a little, i've had web services returning 5000+ records in under a second, from a different machine. But this delay is not bad, it is perfectly acceptable depending on how you present it to the user. If you want a slightly faster UI (silverlight can be a little slow), then maybe a click once WPF or an WPF xbap embedded in a web page would suit you better. WPF is faster than Silverlight, and utilises the full .Net framework, not a cut down version - in fact WPF has *many* positives.
slugster
Actually I have a year experience in WPF and I feel pretty comfortable with it. We need SL because of what it gives beyond WPF - platform independence and true web base experience. XBAP is too limited in power. ClickOnce is just a means to install desktop application and it has its limitations. There is always a possibility to package true WPF code as ActiveX and let browser host it, but I've been there and it is not the way I wish to repeat.
mark