Hi Rocky,
We are finally starting to rewrite our WinForms application and for various reasons the winner for the new interface is WPF. However, I'd really like to make sure that we can create a Silverlight front-end as time permits down the road.
I understand that the ProjectTracker sample is out of date, so I was hoping I could get some general guidance setting up my projects.
I was thinking about just having a single Library project that points to the silverlight version of csla.dll. If I do that, would it significantly handicap the WPF version of my application?
Or would I be better off following the ProjectTracker sample by creating a duplicate Library.SL project that has shortcuts pointing to the original Library? Or is there a new approach with 4.0?
Any help is much appreciated.
As a followup question, if I go with two projects (Library and Library.SL) does anyone know of an add-in that will keep the projects synced, so that if I add a file in Project A a link will automatically be created in Project B?
Though it is simple, the best sample right now is Samples\Net\cs\SimpleNTier - especially in 4.1 (only in svn right now). That contains a single, simple n-tier app that has WPF, Silverlight, ASP.NET MVC and WP7 interfaces.
There is a tool from the Microsoft Patterns and Practices group called Project Linker. Someone posted a few weeks ago that they've upgraded it to VS10, and if so then it is what you are looking for in terms of automatically linking files from one project to another.
Looking at the samples, I'm trying to wrap my head around the need for the !SILVERLIGHT pre-compiler statements. I guess i just dont know enough about the limitations of Silverlight. Would the Silverlight for 3.8 videos help me out with that, or would i be better off waiting for newer videos at this point? I already have the MVVM videos.
Also, I'm assuming you could point a WPF UI to a Silverlight business layer. What is the compelling reason not to do that (i.e., have a single Library that is dumbed down for SL)?
There are certain features that just don't exist on SL, such as synchronous data portal calls. So if you want to have sync factory methods in your classes, you need to prevent them from compiling on SL - which is the reason for the #if !SILVERLIGHT blocks.
For my part, I usually build my WPF UIs to be async too, so if my only UI targets are WPF and SL I won't even implement sync factory methods. But if my types are going to be used in ASP.NET MVC (for example), then the sync factories are important.
Right now Csla.dll compiles differently for .NET, SL and WP7. I thought about trying to come up with a "core of CSLA" that could be common across .NET and SL, but that is really challenging.
For example, in .NET I use the new .NET 4 threading features for certain things because having the best possible implementations is really important in a multi-user, multi-threaded server environment. SL4 doesn't even have those features, so the SL codebase uses my own implementation. And that implementation is fine, but I am pretty confident that the new threading stuff in .NET 4 is better. If I'd created a common Csla.dll I'd be entirely limited to SL functionality, and couldn't use the .NET 4 features.
Thanks for the explanation. It makes more sense now. Compiling two versions of the Library isn't a big issue, but unless I'm missing something I'd also have to create two versions of every project that references my business library.
For example, we currently have a Common.UI.Controls project that is referenced by two different WinForms applications. It sounds like I'd have to create a Common.UI.Controls.SL if I keep the current solution structure. Or better yet, rework the controls so that they don't reference the business objects directly.
Anyway, something to keep in mind. Thanks again for your time.
I'm not sure what you mean by two versions of every project?
Typically my SL solutions, often with some web or service components on the server, look like this:
Of all that, only the Library.Net and Library.Sl share their files. All the other projects are unique to a specific platform.
Our current solution is broken up more is all. We have one UI project for our end-user application, another UI project for a separate administration application, a project for shared UI controls, and finally a project with all of our DevXpress reports in it. Since they all reference the business objects, I would have to create two versions (one referencing the WPF library and another referencing the SL library) for each project IF I kept the same structure, right?
So I'll probably just restructure things a bit for the rewrite. For the record, I inherited the current structure =)
Sorry to dig this back up, but I'm really confusing myself over here.
If we decide to go silverlight completely and will never (for the sake of argument') use another UI , what kind of project should my dataportal be and which version of csla.dll should it reference?
When I create a .NET dataportal referencing "server/csla.dll" and my Library.SL project, there's a warning icon in my reference list.
I'd really prefer not to have two library projects if possible.
The data portal has to be hosted somewhere - IIS/ASP.NET, Windows Server AppFabric, WAS or a custom Windows service. This is true for all scenarios where you do 3- or 4-tier deployments.
The data portal has two possible endpoints - .NET and Silverlight. And your data portal can have both - they are just different svc files.
In all cases, the data portal is running in .NET of course, so it uses the .NET assemblies.
There is no Silverlight data portal host - I'm rather skeptical that you could do that even if you wanted to.
Copyright (c) Marimer LLC