Причина, почему блок Silverlight не двоичный совместимый с “нормальными” блоками.NET

К ответу на обновленный вопрос это - проблема курицы/яйца. Лучший способ выровнять по ширине расход состоит в том, чтобы показать, как он уменьшает стоимость где-то в другом месте, таким образом, Вы, возможно, должны провести некоторое дополнительное/персональное время для изучения чего-то сначала для создания некоторого функционального прототипа.

Шоу Ваш босс демонстрация как "эй, я сделал эту вещь, и это экономит мне, это много времени [или еще лучше, это много $$], воображает, могли ли все использовать это, сколько денег мы сэкономили бы"

и затем после того, как они соглашаются, объясните, как это - некоторая другая технология и что это стоит расхода для получения большего количества обучения и обучения другим о том, как сделать это лучше.

6
задан Konstantin 16 November 2009 в 12:36
поделиться

3 ответа

Так, хороший вопрос. В этой области существует множество заблуждений, и важно отделить факты от вымысла.

Художественная литература: Сборки Silverlight компилируются волшебными гномами Microsoft, что делает их несовместимыми с настольной CLR .Net.

Факт: CLR имеет прекрасно сформулированную систему под названием « Fusion ».
Каждая сборка имеет манифест сборки, встроенный как часть DLL / EXE.
Манифест сборки содержит множество вещей (имена встроенных ресурсов, информацию о системе типов и т. Д.), А также то, какие другие сборки требуются для этой сборки.

Fusion - это часть среды CLR, отвечающая за принятие этой зависимости манифеста сборки и поиск соответствующего физического файла.

Fusion для сборок Silverlight на настольной среде .Net CLR - просто работает. (при условии, что присутствуют все зависимости)

Fusion на Silverlight CLR для настольных сборок - не будет работать.
В основном потому, что библиотеки DLL .Net BCL (библиотеки базовых классов) просто нет. Как уже упоминалось, это разные mscorlib.dll, agcorlib.dll, System.dll, System.Windows.dll и т. Д.
Причина, по которой эти библиотеки различаются, заключается в , прежде всего, в безопасности . Обычный BCL выполняет все виды неприятностей с указателями, специфичными для платформы вызовами / вызовами, файлами, реестром и т. Д. И у нас не может быть этого, просто запустив браузер.

Итак, подводя итоги:
Сборки Silverlight -> Запуск на рабочем столе CLR == Работает
Сборки рабочего стола -> Запуск на Silverlight CLR == Не работает

Если вам нужен реальный пример сборок Silverlight, работающих на настольной среде CLR, ознакомьтесь с моей статьей год назад @ SILVERLIGHT DLL НА РАБОЧЕМ СТОЛЕ CLR

9
ответ дан 10 December 2019 в 02:49
поделиться

Код IL тот же. Однако основные библиотеки отличаются, поэтому даже простейшая операция в библиотеке, скомпилированной для .NET, не будет работать в Silverlight, поскольку библиотека будет ссылаться на внешние библиотеки, отсутствующие в Silverlight.

0
ответ дан 10 December 2019 в 02:49
поделиться

Несовместимы, поскольку Silverlight использует облегченную версию mscorlib.dll. Однако вы можете повторно использовать свой код, написанный для «обычного» .NET, на Silverlight с помощью некоторых приемов.

0
ответ дан 10 December 2019 в 02:49
поделиться
Другие вопросы по тегам:

Похожие вопросы: