   [.net] WPF/Silverlight
  Hi all,After a year or two of WPF development, management has decided that it might be worth looking into Silverlight. After a few days investigation, the conclusion I've come to is that sharing UI components between WPF and Silverlight is either impossible or so much work as to be not worth while.Does anyone have any experience with this? Any advice? Is Silverlight worth it for a LOB app?   
  It depends on what you need the app to do. Silverlight isn't impossible and it's not any more work than WPF, depending on what you need to do.   ;  At this time they are somewhat source code compatible and if you have very clean (business/DTO) objects you can share those at assembly level. Some templates and styles could be compatible as well.   ;Quote:Original post by ernowAt this time they are somewhat source code compatible and if you have very clean (business/DTO) objects you can share those at assembly level. Some templates and styles could be compatible as well.I do have a clean business object library but can you elaborate on what you mean by "share those at assembly level"? As for sharing UI components, it's actually not really practical. Silverlight doesn't support commands, multibinding or triggers. Also, it uses the VisualStateManager which WPF is just starting to support (i.e. none of my existing code will work in silverlight);Have a look at thisSilverlight 4 does support commands and for triggers I recommend the alternative in the Blend SDK: behaviors.In my opinion it is not worth the hassle to keep one code base for both environments (except for the DTOs perhaps);Quote:Original post by ernowHave a look at thisSilverlight 4 does support commands and for triggers I recommend the alternative in the Blend SDK: behaviors.In my opinion it is not worth the hassle to keep one code base for both environments (except for the DTOs perhaps)Thanks ernow, that is interesting. I tend to agree with you regarding the code base. Will look into the sharing assemblies. Shame you can't use project references (no debug/release support);  I've been trying to find a solution for this problem too. Here's how I arranged my projects:-Common non-GUI codebase (non-Silverlight project)-Common controls, with links to all source files in common project (Silverlight project)-WPF app, with links to all GUI source files in common controls and reference to common assembly-Silverlight app, with reference to common GUI assemblyYou can link to a file instead of copying it into your project using the combobox on the Add button. It's a pain to maintain the links and it will put friction on your refactoring.The reason the common GUI project is Silverlight is because SL is somewhat of a subset of WPF and so I'll be restricted to using SL-compatible code. If I need to do something specific to SL or WPF, I use a #if block.I recently tried referencing a Silverlight assembly from my .NET 4.0 project. VS gives a warning, but it appears to work in simple cases. If you need functionality more specific to either framework, such as sockets as I did, you're back to dealing with links.   