I am wondering what the advantage or reasoning is behind using linked files in the CSLA Light project for shared code from the core CSLA project? I understand that we are dealing with two different runtimes, but is it not possible to use a shared library that contains the common types for both?
I have a similar situation with some domain code that I will need to share between applications running under .NET and Silverlight. My first instinct was to pull this code out into a common, shared library but now I'm thinking this won't work unless that shared library is recompiled for each platform.
Isn't there a risk that my common code may reference types or use code (such as reflection) that can't actually be shared? Will that show as a compilation error when I build my Silverlight library?
Yes,
you will get the error. You have to have two projects for shared code –
one for each runtime. You can exclude code that is not to be run under
one runtime by using compiler directives just like all sample Silverlight
projects do.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: SonOfPirate
[mailto:cslanet@lhotka.net]
Sent: Sunday, August 02, 2009 9:19 AM
To: Sergey Barskiy
Subject: [CSLA .NET] Shared library versus linked files for CSLA Light
I am wondering what the advantage or reasoning is behind using linked files
in the CSLA Light project for shared code from the core CSLA project? I
understand that we are dealing with two different runtimes, but is it not
possible to use a shared library that contains the common types for both?
I have a similar situation with some domain code that I will need to share
between applications running under .NET and Silverlight. My first
instinct was to pull this code out into a common, shared library but now I'm
thinking this won't work unless that shared library is recompiled for each
platform.
Isn't there a risk that my common code may reference types or use code (such
as reflection) that can't actually be shared? Will that show as a
compilation error when I build my Silverlight library?
It would be ideal to have a shared library, absolutely.
Unfortunately that is not a supported scenario - .NET assemblies won't run on Silverlight and visa versa.
At Tech Ed earlier this year I had an attendee tell me that he had been able to get a simple Silverlight assembly to run on .NET. I talked to (and he did too I think) Microsoft people about that, and it was a fluke, or at best an unsupported hack.
You are not alone in wanting to do this though, and I'm sure many of us are telling Microsoft that we'd like some way to run Silverlight code on the server (or some variation on this theme). I'm not sure how such a thing would work, but maybe they'll consider it at some point in the future.
Forgive my ignorance, but I am a Silverlight newbie. If I'm understanding the problem correctly, it is not just that we are compiling for a different runtime but that the framework assemblies we reference are different between the two, correct? I can see how this would prevent us from having any shared libraries.
I was thinking recompiling for the appropriate target was all that mattered but it sounds like the issue is more deeply rooted.
My concern, as I'm sure you are well aware, is duplication of code resulting in higher maintenance costs and greater risk as bugs fixed in one framework aren't fixed in the other.
The ability to add linked files is new to me but would it make sense too create a Shared Code folder that sits "between" the two frameworks with each project linking to the actual source file residing in this folder? Then, if a change is made, it will be reflected in both projects. There wouldn't actually be a shared assembly but the code would be - making maintenance a bit more reliable.
What do you think?
All I can suggest is that you play with it and see if you can
derive a better overall answer.
One thing that does help is the Project Linker, which is a
sub-project of the Prism effort from Microsoft Patterns and Practices. It could
use some flexibility, but it is a good first run at a solution.
Copyright (c) Marimer LLC