Комментарии 27
Правда у меня ситуация была другая — мне надо было перенести Cordova приложение на Windows Desktop. Поэтому в приложение был добавлен еще и вебсервер и прилеплен механизм обмена данными. Под виндой работало, а вот под МакОС (использоваля PureBasic) то работало, то нет, то снова работало. Подозреваю, что необходимо было разность приложение, WebView и вебсервер по разным потокам…
https://msdn.microsoft.com/en-us/library/ee330720(v=VS.85).aspx
Более того, безболезненно можно писать права на старте приложения и стирать при выходе. Права выше юзерских не нужны. Никаких системных и тем более чужих ключей при этом не затрагивается.
Настройка есть, не всегда приложению туда дают лазить. Собственно и правильно делают. Одна настройка для всех.
WebBrowser компонент — это всегда IE причем зачастую неожиданной версии на машине у пользователя. IE сам по себе боль, а когда нужно под него писать не зная конкретную версию (а зачастую зная что лучшее на что можно надеяться это IE6 — enterprise для медицины или банков напр.) — то боль становится невыносимой.
Даже если мы решаем, что наше приложение это .NET framework 4.0, то разброс версий IE которые будут представлены в системах клиента — это IE8 — IE11 причем на системах с разными способами рендера шрифтов (Win XP — Win 10), разными способами масштабирования.
Когда нам надо было кусок нашего web приложения встроить в rich client на winforms, то повоевав с недельку с WebBrowser компонентом и поняв что доставшийся от контракторов backbone код под него не был заточен и фиг перезаточишь — решили пересесть на движок на базе чего-то другого firefox или chrome. Перепробовав многие из них остановились на CEFSharp. Да возни с его настройкой побольше, чем с WebBrowser control, сборка сложнее, но оно того стоило. Во-первых фиксированая версия браузера, которая не зависит от левой пятки админа в сети клиента. Во-вторых это chromium с родным V8 а значит JavaScript быстрый. В-третьих это WebKit/blink а значит и возможности по рендеренгу HTML повыше. Ну и все радости кастомизатора вроде получения событий и самостоятельная обработка сетевых запросов — в наличии.
Мое мнение на основе горького опыта. WebBrowser Control — если рендерим что-то очень простое или строго для себя (для внутренних нужд компании), если что-то пойдет вовне — лучше использовать другие средства.
Точных чисел не дам сейчас, но порядок — 100мб.
Сразу несколько тем в одной
1) 100Мб может быть как много так и не много в зависимости от ситуации. Если у вас что-то вроде условнобесплатной утилитки, то пожалуй 100мб это серьезный барьер для пользователей. В нашей ситуации размер приложения был далеко не самым важным фактором.
2) Легких браузеров (встраиваемых или нет) нет, потому что все движки довольно сложные. HTML/CSS сложный язык, а внутри еще и JavaScript, и flash, и воспроизведение кучи всяких медиа форматов, плюс шифрование, плюс ресурсы, плюс XML часто, плюс инструменты разработчика итд итп. Если попробуете все это сами запаковать в меньший объем — убедитесь что это не так-то просто.
Если вам нужен только HTML + CSS рендерер, то есть другие и более легкие варианты. Тот же blink/webkit отдельно бывает под разные языки. Опять же если HTML у вас простой — то WebBrowser control вполне подойдет, если нужен JS — то где-то здесь была ссылка на статью, где автор все отдельно запиливал.
Если же вам нужен просто интерфейс который можно динамически строить на каком-то декларативном языке, так тот же XAML, XUL, QML ну или миллион других опций в зависимости от языка и платформы. HTML/CSS — не лучший вариант (ибо слишком сложный формат и куча не нужного вам).
Ну а серебряной пули, которая при этом еще и маленькая увы нет.
Если же вам нужен просто интерфейс который можно динамически строить на каком-то декларативном языке, так тот же XAML, XUL, QML
Ну для .NET из коробки только XAML. Все остальное с костылями и следовательно заранее неизвестным количеством граблей на которые придется наступить. В этом плане на фоне прочих 'неродных' решений HTML пожалуй будет предсказуемее что ли. А так, теоретически, к примеру при наличии в проекте веб-частей, возможно использование суммарно на одну технологию меньше перекрыло бы 'не лучшесть' этого варианта.
Но в любом случае я согласен что что-либо серьезное пока только на сторонних движках можно делать, ибо всегда чем меньше приложение зависит от внешних факторов тем лучше.
Если попробуете все это сами запаковать в меньший объем — убедитесь что это не так-то просто.
В этом я и не сомневался. Но вот почему бы не позволить делать кастомные сборки только с нужными функциями? Например, я увернен, что флеш мне не нужен и никогда не понадобится. То же самое с инструментами разработчика, воспроизведением медиа и тд.
Так ведь вам никто и не запрещает делать кастомные сборки. Можете отдельно webkit взять, отдельно javascript, итд итп. Только собрать все это вместе и проинтегрировать — это примерно объем работы которым заняты разработчики современной opera или vivaldi. Ну это если вы хотите чтобы у вас в окошке крутились angluar или backbone приложения. А если вы хотите просто на html рисовать морду и всю логику на том же C# обрабатывать, то задача существенно проще.
Эта пара фреймворков, конечно, заметно увеличивает размер приложения, добавляя мегабайт 50 к инсталятору. Зато приложение получается кросс-платформенным. Вот один из примеров — CatLight catlght.io
WPF Browser Applicaiton не заворачивается в html, такое приложение загружается браузером и запускается в отдельном процессе PresentationHost.exe, просто parent-окном является браузер. На такой «странице» с этим xbap-приложением HTML отсутствует в принципе.
То что вы советуете диаметрально противоположно сути статьи. Суть — рисовать UI десктопного приложения на HTML _вместо_ XAML или WinForms, и встраивать в приложение браузер для его отрисовки. Подчеркну — десктопное приложение, с полными возможностями десктопных приложений и без неободимости использовать к-л сервера. Вы же советуете взять «десктопное» приложение с десктопной технологией UI (xaml ни в какой html при выполнении не трансформируется) и запихнуть его тем самым в браузер, причем непонятно зачем, поскольку никаких преимуществ по сравнению с обычным wpf приложением при использовании в качестве standalone-приложения это не даст, зато на ровном месте получаем кучу ограничений песочницы в которой оно выполняется и которые еще руками отключать придется.
Используем HTML и WebBrowser control в качестве UI для обычных windows-приложений на C#