Как я могу использовать блоки не-Silverlight в приложении Silverlight?

На самом деле, пока это трудно и вероятно не хорошая идея, возможно сослаться на блоки CLR в проекте Silverlight. У David Betz есть пример на его блоге: http://www.netfxharmonics.com/2008/12/Reusing-NET-Assemblies-in-Silverlight

Снова стоит подчеркнуть, что Вы, вероятно, действительно не хотите делать это. Платформа Silverlight была разработана опытными инженерами, которые поместили длительное размышление в то, что должно быть включено и что не было должно. Думайте об объектах CLR, что Вы думаете, что нуждаетесь и пытаетесь понять, почему они не в настоящее время доступны, и каковы альтернативы.

Наконец, помните, что любой CLR возражает, что Вы действительно добавляете, увеличит размер Вашей загрузки.

Нет. Источник csproj должен знать, что это - проект Silverlight. Это может означать сохранять два файла проекта с тем же источником ".cs" файлами. Существует удобный прием csproj здесь - (скопированный с protobuf-сети, где я делаю это для нескольких платформ):

<ItemGroup>
    <Compile Include="..\YourMainProject\**\*.cs" />
</ItemGroup>

Затем только необходимо поддержать один проект; проект Silverlight получает все от дерева.

Обратите внимание, что BCL Silverlight в большой степени ограничивается, и не вся функциональность будет доступно. Получение кода, который компилирует и на регулярной.NET и на Silverlight, может быть... сложным.

С другой стороны, используйте прокси-классы в приложении Silverlight (т.е. через WCF и т.д.). Не как богатый, но простой сделать.

Никакой it't, не возможный к ссылочным блокам, которые не создаются против времени выполнения Silverlight.

Путем я двигался, это должно создать новый проект для моих бизнес-блоков и затем добавить все классы от исходного блока до него. Ключ - то, что, когда Вы добавляете их, делают это как существующий объект и на Добавить нажатии кнопки стрелка вниз и Добавляют как Ссылка. Тем путем у Вас все еще только есть единственная кодовая база, хотя Вам, вероятно, придется добавить несколько классов, таких как ApplicationException для восполнения вещей, отсутствующих во времени выполнения Silverlight.

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

Хорошие новости однако - то, что у Вас есть большое количество обходных решений. Это сообщение в блоге и эта статья CodeProject обсуждают вопрос подробно и предлагают множество чистых решений. Надежда, которая помогает...

Время выполнения Silverlight является подмножеством основного.Net CLR. Хотя это, может казаться, боль существует разумная причина ее - время выполнения Silverlight должно быть достаточно легким, чтобы быть плагином браузера.

Если Вы помещаете свои другие классы позади веб-сервисов затем, они могут работать под полным временем выполнения .NET в то время как Ваше выполнение приложения Silverlight при сокращении вниз CLR в плагине Браузера.

Сразу предупреждаю, мой опыт в этом вопросе основан на разработке для Windows Phone 7, так что это может незначительно отличаться от обычного Silverlight 3.

JaredPar отметил, что Silverlight CLR несовместим с обычным CLR. Это не на 100% верно, поскольку сборки, скомпилированные как библиотеки Windows, будут работать под Silverlight при условии, что они используют поддерживаемые API. Вы можете вручную отредактировать проект silverlight и добавить ссылку на обычную сборку .NET. Обратите внимание, что вы можете добавить ссылку только на скомпилированную сборку, а не на проект.

Приложение silverlight скомпилируется и запустится, но как только оно попытается использовать класс, которого нет в Silverlight, вы получите ошибку времени выполнения.

Чтобы продемонстрировать разницу в API, посмотрите на следующие скриншоты. Как вы видите, обе сборки имеют несколько общих API, но в сборке Silverlight некоторые из них отсутствуют. Как только ваша сборка попытается обратиться к этим API, приложение взорвется!

Full .NET 4.0 mscorlib (System.serialization namespace):

Full .NET 4.0 mscorlib http://img188.imageshack.us/img188/2131/fullmscorlib.png

Silverlight 3 mscorlib (System.serialization namespace):

Silverlight 3 mscorlib http://img526.imageshack.us/img526/4254/sl3mscorlib.png

Недостатком связывания полной .NET сборки является то, что вы не будете знать до выполнения, какие API не поддерживаются. Учитывая, что потенциально некоторые поддерживаемые системные API могут использовать неподдерживаемые системные API, нет простого способа выяснить это заранее.

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

Итак, теперь при компиляции чего-то, что ссылается на API, отсутствующий в Silverlight, вы получаете ошибку:

public class SerializableExample: IEquatable<string>, System.Runtime.Serialization.ISerializable
{
}

error CS0234: The type or namespace name 'ISerializable' does not exist in the namespace 'System.Runtime.Serialization' (вам не хватает ссылки на сборку?)

С помощью условной компиляции (a-la good ol' C/C++ days) вы можете отключить то, что не поддерживается:

public class SerializableExample: IEquatable<string>
#if !SILVERLIGHT
  , System.Runtime.Serialization.ISerializable
#endif
{
}

Microsoft также предоставляет инструмент Project linker tool, который позволяет автоматически обслуживать проекты, содержащие связанные файлы. К сожалению, текущий релиз не работает в VS2010, возможно, вы можете скомпилировать исходники и сделать это, но я не пробовал.

http://msdn.microsoft.com/en-us/library/dd458870.aspx

Прямая ссылка на скачивание:

http://download.microsoft.com/download/6/3/8/6382E28D-2EBD-4A4E-BB76-6F425E1C9DB9/MicrosoftPracticesProjectLinkerFeb2009.msi

Эта страница Microsoft описывает mult-targeting в мучительных подробностях.

Вы пробовали это? Он может собрать Silverlight Assembly напрямую, щелкнув правой кнопкой мыши на проекте библиотеки .NET.

http://buildassilverlight.codeplex.com/