Ориентация на .NET 3.5 и Silverlight

Предположим, у меня уже есть проект по сборке .NET 3.5. Теперь я хочу построить эту сборку для Silverlight и, кроме того, сохранить ее версию Silverlight с минимальными усилиями далее.

Что неприемлемо:

Создание отдельного проекта для сборки Silverlight

Что приемлемо:

Добавление пользовательских директив, позволяющих мне настроить либо Silverlight, либо .NET в зависимости от того, например. Свойства MSBuild.
Добавление специальных конфигураций сборки для Silverlight
Добавление разделов #ifdef Silverlight/#endif в исходный код.
Как правило, любая другая модификация .csproj/.cs.

Итак, в основном, я хотел бы поддерживать один проект, но целевые две структуры. Я не хочу поддерживать два отдельных проекта, потому что это может привести к ошибкам, например, забыть о включении нового файла. Если есть много проектов и большая команда, это действительно важно, чтобы исключить такие ошибки.

Если это совершенно невозможно, любое решение, обеспечивающее аналогичные преимущества, приемлемо.

Ответ 1

Вы также исключили ссылку на файлы внутри вашего проекта из проекта Silverlight? Это довольно распространенный подход к совместному использованию Silverlight и полной CLR. Общий код между платформами .NET и Silverlight

Кроме того, согласно Justin Angel, вы можете ссылаться и использовать библиотеку классов Silverlight из полной CLR. Я не пробовал это сам, и он оставляет некоторые вопросы без ответа, но это делает простой сценарий: http://silverlight.net/blogs/justinangel/archive/2008/12/29/using-silverlight-dlls-on-the-desktop.aspx

Ответ 2

Я согласен с Скоттом. Спасите себя от боли. Это два проекта, которые используют одну и ту же базу кода. Вам понадобится использовать VStudio в обеих средах, использовать разные библиотеки, включать /exculde файлы, делать так много всего... легко!

Причина того, что два проекта далеко превысят оправдания за его использование.

Ответ 3

MSDN содержит подробную информацию о платформе Multi-targeting: Мультитаргетинг в MSDN

Ответ 4

У вас должно быть два проекта, потому что ссылки mscorlib отличаются для двух платформ.

Посмотрите на этот вопрос: http://www.google.ca/search?hl=en&q=targetting+silverlight+and+wpf&meta=&aq=f&oq=

Если все, что вы хотите сделать, это обычная старая библиотека .NET, которая была разделена между ними, тогда я предлагаю создать два проекта (один для Silverlight, один для обычного) и в том числе те же файлы в обоих проектах. Это гораздо легче понять для других разработчиков.

Ответ 5

Я думаю, что вам нужно сделать это правильно. Ваш код Silverlight должен быть только для пользовательского интерфейса и связи с бэкэнд-услугами WCF. Эти службы будут запускать ваш код .NET 3.5 (код, который вы хотите предоставить). Таким образом, у вас есть общий доступ и n-уровень.

Если вы делаете большой расчет на стороне клиента в своем коде Silverlight, а затем отправляете его на сервер (и, возможно, db), то я думаю, что вы открываете дыру в безопасности.

У вас нет убедительной причины, по которой отдельный проект должен получить доступ к коду в проекте Silverlight.