Does anyone have experience with writing code that's meant for use in both Silverlight 2 and .NET 3.5 application?  One option appears to be creating a separate project for each platform.  One of the projects would add the files as a link.  With this solution, code that is specific to one platform or another would simply not be included where it won't build.

Another solution might be to create a single project (which is easier to manage than 2) and use preprocessor directives to hide code that won't build for a specific platform.  Then I might have different configurations that define these directives for the platforms and I could choose the configuration I want to target during each build.

In general, what's a good practice for going about this approach?  I'm hoping to avoid duplicate code bases for SL and .NET 3.5.

Thanks,

James

James,

I 'm doing something equivalent, but with code shared between ASP.NET, Silverlight 2 and WPF.

The approach I'm using is to create 3 DLL projects, one for each target. The source files are then inserted in each project, using a link. In the projects, I define conditionals that I can use in the source code, to remove part of the code that is not available (or not useful) in a specified target (for example, SQL definitions in Silverlight 2).

The DLLs contains all the code that is shared by more than a target. I then create a "main" DLL or EXE (for WPF), that contains the code that is specific to a target. In a perfect world, the WPF exe should contain only the application definitionand, eventually, the command-line parameters. In the case, I'm actually writing, there is more than a single WPF application with the same code base (they are making things really too different between them to use the same UI).

The problem of creating a single project is that the frameworks are not the same between Silverlight 2 and the other target, so the assembly created for WPF cannot normaly be used in a Silverlight project. Even if it can be used, there is a risk to use a method that doesn't exist in Silverlight and to see the error only at runtime. This approach leaves also open the door for a Compact Framework port with the same code source (with a 4th DLL project, of course).

At the end, I have 6 projects in the solution and I can compile the three application at the same time.

Patrick

You cannot hope to use the same assembly across both Silverlight and .NET. The security model is entirely different (no CAS in Silverlight, I believe), not to mention the various assembly references etc.

So you really need separate projects. We use separate projects and link source files to each project as appropriate. Aside from a little work managing the [somewhat] duplicated project structures, it's all quite simple.

We try avoid conditional code (#if) by making sure the source files are appropriately segregated (in other words, if we have Silverlight-only or non-Silverlight code in a source file, we generally split the file to separate the behaviours).

Kevmeister:

We try avoid conditional code (#if) by making sure the source files are appropriately segregated (in other words, if we have Silverlight-only or non-Silverlight code in a source file, we generally split the file to separate the behaviours).

This can be quite complicated, when we have 3 targets (in my case):

• Silverlight only code.
• ASP.NET only code.
• WPF only code.
• Code common to Silverlight and WPF.
• Code common to the three platforms. 
• Eventually other combiations.
  

This means at least 5 source files for some classes...
Even for 2 targets it could be up to 3 source files for a class.

Patrick

 James,

 I've highlight my strategy here.

If it is only 2 platforms, I prefer hosting the source in the "sub-set" framework - in your case - Silverlight.
If > 2 platforms (Compact framework / Silverlight / .NET 3.5) - then I keep the files completely seperate in a shared location (no project), and link them in on a per-project basis. I usually maintain a solution folder that contains all the shared files in this case.

As highlighted in my blog post, extending shared code logic use either partial classes, or inheritence, whichever makes more sense.

I personally do not like compiler directives - it makes for untidy code, and imo is more difficult to maintain. (but I do use it in rare cases when it becomes the simpler solution, as highlighted in above posts - but only as a last resort)

Yes, I guess if there are a lot of permutations then splitting the file might be problematic, but that's not something we've had to deal with. As InquisitorJax points out, though, techniques such as partial classes may help in that regard - which is something we've done in a few places.

I think the PRISM 2 project is trying to tackle the same problem.. If I remember correctly, they have some MultiTargeting/Linking mechanism... They will rename the MultiTargetting in the future to avoid confusion with VS.NET.

http://www.codeplex.com/CompositeWPF

-Chau
DNAfor.NET

-Chau Nguyen
-http://DNAfor.NET