Я использую WPF уже некоторое время и снова и снова понимаю, что Microsoft вкладывает свои усилия в Silverlight, а не в WPF (службы RIA, тема по умолчанию, элементы управления и многое другое).
Я подумал, что было бы неплохо перейти на Silverlight (т.е. создать автономные настольные приложения с Silverlight 4.0), вопрос в том, возможно это или нет.
Кстати, я думаю, что приложения LightSwitch создаются с помощью Silverlight как автономные настольные приложения.
Можно создавать автономные настольные приложения (вне браузерных приложений) с помощью Silverlight версии 3.0 или выше, и это прекрасно работает. Теперь также можно установить приложение вне браузера, даже не открывая браузер, как показано на этом сообщение в блоге .Silverlight великолепен, и приложения Silverlight работают даже на компьютерах MAC и Linux (ограниченная поддержка).
Однако неправда, что Microsoft инвестирует только в Silverlight. Microsoft также инвестирует в WPF. Хотя с помощью Silverlight можно создавать браузерные приложения, они имеют множество ограничений по сравнению с полноценными приложениями WPF. доступ и т. д. Таким образом, если ваше приложение является просто бизнес-приложением, и вам не нужно напрямую обращаться к аппаратным устройствам или базе данных, то Silverlight может быть вариантом, однако, если ваше приложение напрямую обращается к аппаратным ресурсам клиентских машин, вам лучше использовать WPF.
Мое предложение: если вы заранее знаете, что это будет настольное приложение, используйте WPF (или, может быть, даже XBAP). По моему опыту, полезные приложения со временем растут, новые функции время от времени запрашиваются. Если в будущем потребуется функция, которая не может быть реализована с помощью Silverlight и может быть реализована только с помощью WPF, у вас будут большие проблемы, потому что вам нужно переписать свое приложение в WPF, и вам будет трудно убедить своего финансового директора. выделить больше средств только для реализации одной функции. Silverlight не предназначен для разработки настольных приложений, его основная цель — мультиплатформенная поддержка.
Из MSDN:
Приложения Silverlight 3 больше не ограничены запуском в браузере. Их можно запустить в браузере или отсоединить от браузера и запустить с рабочего стола. Эти внебраузерные приложения позволяют перенести все богатство приложений Silverlight 3 непосредственно на рабочий стол без ограничения работы в браузере.
Ссылка: Создание внебраузерного клиента с помощью Silverlight 3
Silverlight 3 поддерживает функциональность вне браузера.
Цитата с страницы Silverlight в Википедии:
Silverlight 3 поддерживает работу вне браузера, т. е. приложения Silverlight можно установить в систему для автономного доступа (при условии, что манифест приложения предназначен для локальной установки), где они запускаются вне браузера.
Также здесь приведен краткий как
Внебраузерные приложения имеют те же ограничения безопасности, что и браузерные приложения.
С Silverlight 4 вы можете создавать приложения с полным доверием, которые имеют полный доступ к компьютеру.
Подробнее об ограничениях доступа к сетевой безопасности в Silverlight
Если вы имеете в виду приложения вне браузера, конечно. Приложение Seesmic Desktop 2 — отличный пример одного из таких приложений с собственным механизмом обновления. Кажется несложным использовать подключаемую модель XAP/MEF и Silverlight таким образом. Seesmic Desktop 2
Мы разрабатываем OOB-приложение в том же духе, одна загрузка из Интернета, и все готово. Однако вы не получите точно такие же API, как в WPF.
Как указывали другие, приложения Silverlight можно установить для работы «вне браузера», но даже при повышенном доверии они по-прежнему имеют значительные ограничения на то, что они могут делать, и, конечно же, не имеют «полного доступа к компьютеру».
Создавая приложение с нуля, вы можете подумать о параллельных сборках Silverlight и WPF. Код можно более или менее совместно использовать, добавив файлы .cs из одного проекта (например, WPF) в другой (Silverlight) с помощью «Добавить как ссылку». Файлы XAML не могут быть связаны таким образом и должны быть продублированы, но это может включать не более чем копирование и вставку, в зависимости от вашей структуры. В сети есть хорошие примеры этого.
Параллельная разработка обоих типов, вероятно, потребует гораздо меньше усилий, чем необходимость резкого переключения типов в какой-то момент и слишком позднее обнаружение несовместимости/ограничений.
