IMO, Having different namespaces (e.g. *.Desktop or *.Silverlight) is not very good idea

Dec 7, 2008 at 7:58 PM

I started playing with Prism v2 drop 7 today and I notice that having different namespace  (e.g. *.Desktop or *.Silverlight) is giving me a lot of problems in compiling the linked files.  I'm thinking to share ModulesCatalog.xaml in both WPF and SIlverlight project but I can't because the Prism assembly (Microsoft.Practices.Composite.Silverlight and Microsoft.Practices.Composite.Desktop) for WPF and Silverlight are different.

Creating the modules under different namespace is not very good. For example: I like to share some class files (e.g. Bootstrapper.cs, PresentationModels or etc) but I always need to change the namespace since I created the projects like CALSample.Shell and CALSample.Desktop or etc..

So, I think it would be the best if we can have the same namespaces for both WPF and Silverlight. What's your thoughts?

Dec 8, 2008 at 4:15 PM
Hi Michael,

I shared your concerns (trying to figure out how to share via linked files) - I then stumbled upon the QuickStarts\MultiTargingQuickstart and all was revealed :) 

In a nutshell they create the "Project names" with the .Desktop and .Silverlight extensions but the namespaces themselves don't contain the extensions (they strip them off of the project namespace configuration) so there is only one consistent namespace for both sides.

FYI, I had started with the QuickStarts\Visual Composition\TopDownUIComposition (we're moving to Separated Presentation Pattern for our next project) which threw me a curve because in this project the Desktop code is the source and the Silverlight files link to them - which is how I started.   At least until I read in the documentation that P&P recommends making the Silverlight code the source and have the desktop link to them.   Consistent with P&P our team will develop for Silverlight and link from desktop (for MultiTargeted applications).

Excerpt (copy/pasted) from Documentation Multi-Targeting Design Concepts follows:

Multi-targeted Elements

The interaction patterns will be different between WPF and Silverlight because you are running inside a browser. If you split your application into smaller parts, it's more likely that you will be able to reuse certain parts.

The ideal approach is to multi-target code that is easily shared between both technologies, typically non-UI code. This will result in an exhaustive use of Separated Presentation patterns to maximize the separation between UI and non-UI code, hence increasing multi-targetable code. Usually you can multi-target the following source code elements:

  • Presenters, although this depends on how different the view is.
  • Controllers
  • Models
  • Services
  • Themeing
  • Unit Tests
  • Simple Views

If you want to share code between Silverlight and WPF, you should develop your application in Silverlight, because the API is more constrained than WPF.

Elements that Should Not Be Multi-Targeted

The following elements should not be multi-targeted:

  • Views (XAML)
  • Controls
  • Styling