Мы написали небольшую библиотеку классов Windows, которая реализует методы расширения для некоторых стандартных типов (строки изначально). Я разместил это в библиотеке, чтобы любой из наших проектов мог использовать его, просто ссылаясь на него и добавляя с помощью XXX.Extensions.
Проблема возникла, когда мы хотели использовать некоторые из этих методов в Silverlight. Хотя весь код был совместим, в Silverlight нельзя ссылаться на библиотеку Windows, поэтому мы создали библиотеку Silverlight, имеющую ссылки на одни и те же файлы классов, и поместили директивы компилятора в классы, чтобы разрешить разные использования объявлений и пространств имен. Это отлично работало до сегодняшнего дня, когда я добавил новый класс в библиотеку расширений Windows и понял, что мне придется не забывать связывать этот класс с библиотекой Silverlight.
Это не идеально, и я задавался вопросом, есть ли у кого-нибудь идеи для лучшего способа совместного использования методов расширения и другого вспомогательного кода между проектами Windows и Silverlight.
Вы не можете установить ссылку из сборки Silverlight на обычную сборку .NET, но вы можете сделать это наоборот.
Итак, создайте общую сборку Silverlight и добавьте свой код в эту сборку. Теперь вы можете установить ссылку как на вашу обычную .NET, так и на другую сборку Silverlight на общую сборку Silverlight.
Ограничение состоит в том, что вы можете использовать только код, который будет работать как на .NET, так и на Silverlight CLR, но это ничем не отличается от кода обмена.
Поскольку на этот вопрос был дан ответ, есть новое решение от Microsoft, Portable Class Libraries. Здесь - это сообщение в блоге, где они объявили об этом.
Я собираюсь начать с ними раунд для обмена кодами между silverlight и кодом на стороне сервера, который я пишу, поэтому не могу добавить слишком много ссылок на ссылки в данный момент.
Время выполнения Silverlight отличается от обычной среды выполнения .NET. Поэтому вам нужно делать трюки на уровне проекта для совместного использования кода между несколькими платформами.
Вот как я сделал это для контейнера Autofac IoC.
При таком подходе вам не нужно создавать разные проекты для каждой целевой платформы.
PS: есть инструмент Project Linker из Composite WPF, который позволяет связать Silverlight и WPF проектов (создает несколько проектов). Но это выглядит грязно.
существует аналогичная проблема с XNA. Поскольку вы можете настроить таргетинг на несколько разных платформ, вам необходимо иметь разные проекты. Причина этого заключается в том, что библиотеки базового класса, которые ссылаются на проект, являются специфичными для платформы, поэтому у вас не может быть только один проект.
Если вам интересно, вы можете получить представление о в этом блоге:
Перекомпилировать источник для другого платформе, вам нужен другой проект. Причина этого в том, что проекты должны ссылаться на разные сборки для XNA Framework и базовую платформу .NET Framework (Xbox 360 и Zune используют .NET. Compact Framework) и проектов С# не предоставлять поддержку для ссылок разные сборки для разных платформы.
Попробуйте http://buildassilverlight.codeplex.com/
У меня были некоторые проблемы с зависимостями при ссылке на библиотеку классов Silverlight в .NET.
Альтернативный способ использования Visual Studio 2010 и WCF RIA 1.0: