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.
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
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.
The MSDN contains detailed information about platform Multi-targeting: Multi-targeting on MSDN
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.
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.
来源：https://stackoverflow.com/questions/1080348/targeting-both-net-3-5-and-silverlight