Proper solution/project structure for Silverlight apps

Question

I've inherited a solution that uses Silverlight. I'm finding that there are projects that are just about exact clones of other projects, with the only difference being that the clone is a Silverlight project. For example, this is the project and folder structure of a non-Silverlight project:

MyCompany.Entities
-> Entities
-> --> Foo.cs

And now the Silverlight project:

MyCompany.Entities.SL
-> Entities
-> --> Foo.cs

Foo.cs is the same file, on disk, for both projects. Is this right? Is this how Silverlight projects are supposed to be structured? Seems like a lot of overhead and that there should be a better way. If this is correct, why is this structure necessary? What does it accomplish?

Answer 1

Well, Silverlight uses a subset of the .NET framework that is reduced in scope. It's not possible to compile normal .NET project to a Silverlight XAP if the .NET project uses some features that are missing from the Silverlight runtime. But if your .NET project uses only the common areas of the framework, it can be done. However, having two copies of the same .cs file wastes space on disk and also exposes you to risk because you may make a change in one .cs file and forget to change the other accordingly. That's why I keep all the original files in my .NET solution and use the "Add as Link" button when adding them to my project. And apparently so did the person you inherited the solution from. It's not a very weird / esoteric structure, it is recommended in quite a few Silverlight books out there (Silverlignt 4 in Action from Manning springs to mind).