views:

441

answers:

5

Let's imagine I already have a project building .NET 3.5 assembly. Now I want to build this assembly for Silverlight, and moreover, maintain its Silverlight version with minimal efforts further.

What is not acceptable:

  • Creating separate project for Silverlight build

What is acceptable:

  • Adding custom directives allowing me to target either Silverlight or .NET dependently on e.g. MSBuild properties.
  • Adding special build configurations for Silverlight
  • Adding #ifdef Silverlight / #endif sections to the source code.
  • Generally any other modification of .csproj / .cs.

So basically, I'd like to maintain a single project, but target two frameworks. I don't want to maintain two separate projects, because this may lead to mistakes like forgetting to include a new file. If there are many project and big team, this is really important to exclude such mistakes.

If this is completely impossible, any solution providing similar benefits is acceptable.

A: 

You have to have two projects because the mscorlib references are different for the two platforms.

Check out this question: http://www.google.ca/search?hl=en&q=targetting+silverlight+and+wpf&meta=&aq=f&oq=

If all you want to do is have a regular old .NET library that shared between the two, then I suggest creating two projects (one for Silverlight, one for regular) and including the same files in both projects. This is much easier to understand for other developers.

Scott Whitlock
Can I disable \ enable necessary options e.g. with Condition=" '$(SilverlightBuild)' != '' " ?
Alex Yakunin
You can if you want to. But you won't have to because they're incorporated in the two project files. e.g. Each .csproj #defines SL or WPF or NET35. Each csproj includes/excludes whichever files/libs it needs. Also don't link files, put the csproj in the same dir and just "Add -> Existing Item".
Ray
Concerning "can I disable" - I mean "can I maintain a single project using MSBuild Condition atribute?"
Alex Yakunin
A: 

I concur with Scott. Save yourself a lot of pain. Two projects that share the same codebase is the way to go. You'll need it to use VStudio in both environments, to use different libs, to include/exculde files, to do so many things...easily!

The reason's for having two projects far outweight the excuses for having one.

Ray
Please read my comment to Scott's post.
Alex Yakunin
+6  A: 

Have you also ruled out linking to the files inside the your project from a Silverlight project? That's a fairly common approach to sharing an implementation between Silverlight and the full CLR. Sharing Code Between .NET and Silverlight Platforms

Also, according to Justin Angel you can reference and use a Silverlight class library from the full CLR. I haven't tried this myself, and it leaves some questions unanswered, but it does make the scenario straightforward: http://silverlight.net/blogs/justinangel/archive/2008/12/29/using-silverlight-dlls-on-the-desktop.aspx

OdeToCode
Is there any tool allowing me to maintain the original project and Silverlight project with links (or at least the links there) in sync automatically?
Alex Yakunin
In Prism (http://compositewpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=19170) there is a Project Linker. Overview here: http://www.global-webnet.net/blogengine/post/2009/01/10/Project-Linker-sharing-single-code-base-between-Silverlight-and-Desktop-applications.aspx
OdeToCode
Great - I'll wait for other answers, if any. For now it seems that's the best option I have...
Alex Yakunin
This works well in my experience.
James Cadd
A: 

I think what you need to do is tier this out properly. Your Silverlight code should be only for the UI and the communication with backend WCF services. Those services would run your .NET 3.5 code (the code that you want to share). That way you have sharing and n-tier as well.

If you're doing heavy calculation on the client-side in your Silverlight code and then submitting that to the server (and probably the db) then I think you're opening up a security hole.

You haven't given a compelling reason why a separate project would need to access code in the Silverlight project.

jcollum
I'm aware about the architecture of Silverlight \ RIA apps, and I'm asking the question because I know exactly what I need. So the advice is good in general, but here it doesn't suit at all.
Alex Yakunin
There can be many many reasons to do heavy calculations on the clients - e.g. imagine I'd like to sort some data (let's say, 1MB) locally. I already delivered it to the client, and cost of its sorting is much smaller than the cost of getting sorted data directly from the server.
Alex Yakunin
Alex Yakunin
+1  A: 

The MSDN contains detailed information about platform Multi-targeting: Multi-targeting on MSDN

juanjo.arana