Wpf приложение не запускается на другом компьютере
Обновлено: 04.07.2024
Рано или поздно вы отпустите свое приложение WPF в "свободное плаванье". Хотя существуют десятки разных способов передать готовое приложение с компьютера разработчика на настольный компьютер конечного пользователя, большинство приложений WPF используют одну из описанных ниже стратегий развертывания:
Запуск в браузере
Если создано WPF-приложение, состоящее из веб-страниц, его можно запускать прямо в браузере. Ничего устанавливать не понадобится. Однако приложение должно быть готово к тому, чтобы функционировать с очень небольшим набором привилегий. (Например, нельзя получать доступ к произвольным файлам, работать с системным реестром Windows, отображать всплывающие окна и т.д.)
Развертывание через браузер
WPF-приложения тесно интегрированы со средством установки ClickOnce ("однократный щелчок"), которое позволяет пользователю запустить программу установки со страницы браузера. Лучше всего то, что приложения, установленные с помощью ClickOnce, могут быть сконфигурированы так, чтобы автоматически проверять наличие обновлений. Отрицательной стороной является то, что возможности по настройке установки ограничены, и нет никакого способа выполнить задачи конфигурирования системы (вроде модификации системного реестра Windows, создания базы данных и т.п.).
Развертывание с помощью традиционной программы установки
Существует много вариантов создания программ установки. Можно воспользоваться коммерчески распространяемым продуктом типа InstallShield, либо создать установочный файл MSI с помощью шаблона Setup Project (Проект установки) в Visual Studio.
Традиционные программы установки предлагают пользователю хорошо знакомый интерфейс мастера установки, с изобилием средств для передачи файлов и выполнения разнообразных конфигурационных действий.
Другой вариант — применение системы развертывания ClickOnce, тесно интегрированной с WPF. Система ClickOnce обладает рядом ограничений (большинство из них связано с положенным в основу ClickOnce проектным решением), но обеспечивает два существенных преимущества:
поддержка установки со страницы браузера (которая может размещаться как во внутренней сети, так и в Интернете);
поддержка обновлений автоматической загрузки и установки обновлений.
Этих двух средств может оказаться недостаточно, чтобы соблазнить разработчиков отказаться от использования полноценных программ установки. Но если интересует простое, легковесное развертывание, которое работает через Интернет и поддерживает автоматическое обновление, то в этом случае ClickOnce — просто идеальный вариант.
Модель ClickOnce и частичное доверие
Обычные приложения WPF требуют полного доверия (full trust), потому что им нужны права доступа к неуправляемому коду для создания окна WPF. Это означает, что установка автономного приложения WPF посредством ClickOnce вызовет такое же препятствие со стороны системы безопасности, как и установка любого другого типа приложения из Интернета — в частности, браузер выдаст предупреждение безопасности. Если пользователь соглашается, устанавливаемое приложение получает возможность делать все, что разрешено делать в системе текущему пользователю.
ClickOnce работает иначе с более старыми приложениями Windows Forms. Приложения Windows Forms могут быть сконфигурированы на использование частичного доверия и затем развернуты с помощью ClickOnce. В лучшем случае это означает, что пользователь может устанавливать частично доверенное приложение Windows Forms через ClickOnce без какого-либо предупреждения безопасности или повышения привилегий.
Может показаться, что подход Windows Forms лучше, но WPF предусматривает возможность комбинировать частично доверенное программирование и технологию установки ClickOnce. Фокус заключается в использовании модели ХВАР. В такой ситуации приложение запускается в браузере, поэтому ему не нужно создавать каких-либо окон, и не нужны права доступа к неуправляемому коду. Более того, поскольку приложение доступно через URL (и затем кэшируется локально), пользователь всегда запускает последнюю, самую свежую версию.
При проектировании ClickOnce предполагалось иметь дело с простыми, прямолинейными приложениями. Развертывание ClickOnce, в частности, подходит для производственных приложений и внутреннего программного обеспечения компании. Обычно такие приложения выполняют свою работу, опираясь на данные и службы, предоставляемые серверами приложений среднего уровня. Как следствие, им не требуется привилегированный доступ к локальному компьютеру.
Эти приложения также развертываются в среде масштаба предприятия, которая может включать тысячи рабочих станций. В таких средах стоимость развертывания приложений и их обновления довольно значительна, особенно если все это должно поддерживаться администратором. В результате более важно предложить простой и прямолинейный процесс, нежели развитый пакет средств.
Модель ClickOnce также может иметь смысл для прикладных приложений, которые распространяются через Интернет, в частности, если эти приложения требуют частого обновления и не предъявляют строгих требований к установке. Однако ограничения ClickOnce (такие как недостаток гибкости в настройке мастера установки) делают эту модель непрактичной для сложных прикладных приложений, которые выдвигают детализированные требования к установке или нуждаются во взаимодействии с пользователем при выполнении ряда тонких конфигурационных шагов. В таких случаях понадобится создавать специальное приложение установки.
Репутация: 27
Всего: 154
Я решил раз и навсегда пролить свет на эту тему. так как уже достали =)
Что делать если программа написаная с использованием visual studio 2005 не запускается на другом компьютере.
Во первых, следует пояснить, что (почти)любая программа на с++ использует стандартную библиотеку - c runtime library, которая содержит набор функций, используемых программой. Например функции для работы с динамической памятью, со строками, с файлами и много чего еще. Эта библиотека может компоноваться либо динасически, либо статически. Так-же существует release и debug версии библиотеки. По умолчанию, когда вы создаете проект в visual studio, он настроен на использование динамической библиотеки. Поэтому, приложение можно будет запустить только на компьютерах, с установленной CRT библиотекой нужной версии.
Самый очевидный способ решения поблемы - уствновить вместе с приложением нужные библиотеки. Для этого существует Microsoft Visual C++ 2005 Redistributable Package (x86/IA64). Этот пакет устанавливает стандартную библиотеку с++ (MSVCR80.dll) а так-же ATL, MFC и OpenMP библиотеки. После этого ваше приложение можно запускать на этой машине.
Чуть менее очевидный способ - статическая компоновка. Заходим в опции проекта, находим там опции компилятора (C/C++ -> Code Generation), и меняем параметр Runtime Library с "Multi Threaded DLL (/MD)" на "Multi Threaded (/MT)". Для отладочной версии программы нужно поменять "Multi Threaded Debug DLL (/MDd)", на "Multi Threaded Debug (/MTd)". После перекомпиляции, несем программу на любую машину и запускаем.
Репутация: 6
Всего: 162
Следует заметить, что Visual Studio - не единственная среда разработки
А так - спасибо за старания.
Репутация: 27
Всего: 154
Репутация: 85
Всего: 196
Итак, открываем полученный файл exe с помощью вьюера, и ищем по ".DLL" (без кавычек и учета регистра) или другому расширению (например, ".BPL" для BCB), в зависимости от того, на что ругается программа. Будут находиться всякие библиотеки, в т.ч. и стандартные (kernel32.dll, user32.dll и пр.) и не очень. Последние нужно скопировать в дистрибутив. затем ту же операцию повторить для всех библиотек. и так до тех пор, пока не будут найдены все зависимости.
Репутация: 27
Всего: 154
Репутация: нет
Всего: 15
А я depends (Dependency Walker). Не знаю, как в Total Commander, а здесь такого рода ошибки выдаются наглядно.
Репутация: нет
Всего: 52
Модераторы, думаю эту тему стоит закрепить отдельно?
Репутация: 6
Всего: 162
Репутация: нет
Всего: нет
Репутация: 27
Всего: 154
Репутация: нет
Всего: нет
| Цитата |
Заходим в опции проекта, находим там опции компилятора (C/C++ -> Code Generation), и меняем параметр Runtime Library с "Multi Threaded DLL (/MD)" на "Multi Threaded (/MT)". |
При компиляции выдаёт:
( * У меня Microsoft Visual Studio 2008)
Репутация: 6
Всего: 118
использовать ее примерно так:
покажет импортные библиотеки и функции (хотя не умеет делать глубокого сканирования, как, например, depends)
Что-то не поняли? -> Напейтесь до зеленых человечков. эта сверхцивилизация Вам поможет.
Репутация: 1
Всего: 3
| Цитата |
Заходим в опции проекта, находим там опции компилятора (C/C++ -> Code Generation), и меняем параметр Runtime Library с "Multi Threaded DLL (/MD)" на "Multi Threaded (/MT)". |
При компиляции выдаёт:
Балмер! Я узнал тебя
Репутация: нет
Всего: нет
Репутация: 85
Всего: 196
Модератор: для вопросов по билдеру есть свой раздел.
Запрещается!
1. Публиковать ссылки на вскрытые компоненты
2. Обсуждать взлом компонентов и делиться вскрытыми компонентами
- Действия модераторов можно обсудить здесь
- С просьбами о написании курсовой, реферата и т.п. обращаться сюда
- Вопросы по реализации алгоритмов рассматриваются здесь
- FAQ раздела лежит здесь!
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, JackYF, bsa.
[ Время генерации скрипта: 0.1737 ] [ Использовано запросов: 21 ] [ GZIP включён ]
В этом документе обсуждаются сбои в потоке визуализации WPF с особым вниманием к тем, которые вызывают исключение или вызывают висеть приложения SyncFlush NotifyPartitionIsZombie или WaitForNextMessage SynchronizeChannel .
Сбои в SyncFlush, WaitForNextMessage, SynceChannel и NotifyPartitionIsZombie
Разработчики часто сталкиваются с проблемами, связанными с сбоями потоков с Windows Presentation Foundation приложениями WPF. Пользователи могут сообщать о таких исключениях, как:
Стек вызовов исключения начинается с SyncFlush или NotifyPartitionIsZombie . Например:
Приложение также может WaitForNextMessage висеть или , с SynchronizeChannel стеком вызовов, таких как:
Это симптомы сбоя в потоке визуализации. Это сложная задача для диагностики, так как полученные исключения и стеки вызовов являются общими. Отрисовка сбоев потока приведет к одному из стеков вызовов, показанных выше (или незначительному их отклонению), независимо от первопричины. Это делает диагностику проблемы или даже распознавание при двух сбоях или зависаниях связано с одной и той же корневой причиной, особенно сложной.
Описание потока визуализации WPF и его отличия от потока пользовательского интерфейса
Причины упомянутых выше сбоев
Исключения и зависания, указанные выше, возникают в потоке пользовательского интерфейса в результате того, что поток отображения WPF столкнулся со смертельной ошибкой. Существует несколько возможных причин этих ошибок, но поток визуализации не передает эту информацию в поток пользовательского интерфейса. Так как эти исключения и зависает, не являются следствием одной корневой ошибки или проблемы, их нет определенного способа их устранения.
По проекту исключения и стеки вызовов в потоке пользовательского интерфейса не помогают диагностировать проблему. Это потому, что к моменту выброса исключения поток визуализации уже прошел точку сбоя. Критическое состояние потока визуализации поможет нам понять, где и почему произошел сбой, но он уже потерян. Это практически не позволяет человеку, пишушему приложение WPF, узнать, почему произошел сбой или как его избежать. Для Microsoft отлаживаю это в файле посмертной свалки пользователей. Поток отрисовки сохраняет круговой буфер отказа стека вызовов, который мы можем реконструировать внутренне с помощью проприетарного расширения отладки и частных символов отладки, чтобы показать примерную начальную точку сбоя. Однако в момент сбоя у нас нет доступа к таким критически важным состояниям, как локальные, переменные стека и кучи объектов. Обычно мы снова запускаем приложение для того, чтобы искать сбои в звонках, которые, как мы подозреваем, связаны.
Общие причины сбоев
Наиболее распространенные сбои в потоке визуализации WPF связаны с проблемами видео-оборудования или драйвера. Когда WPF запрашивает драйвер видео для возможностей с помощью DirectX, драйвер может неправильно определить его возможности, из-за чего WPF может оказаться на пути кода, что приводит к некоторым сбоям DirectX/D3D. Иногда драйвер не неправильно сообщает о своих возможностях, но он не был реализован правильно. Большинство сбоев потоков визуализации вызваны попыткой WPF использовать конвейер отрисовки оборудования таким образом, чтобы выявить некоторые недостатки в драйвере. Это может произойти в современных версиях Windows с современными графическими устройствами и драйверами, хотя это не так часто, как это было в первые дни WPF. Поэтому одним из первых предложений по проверке и/или работе с отказом потока визуализации является отключение аппаратного ускорения в WPF.
Не исключено также, что сбой вызван приложением с просьбой отрисовки слишком сложной для драйвера (или DirectX) сцены. Это не часто встречается с современными драйверами, но у каждого устройства есть ограничения, и их невозможно превысить.
Другим историческим источником сбоев потоков визуализации является использование свойств Window.AllowsTransparency или Popup.AllowsTransparency в WPF, что приведет к использованию многоуровневого окна. Более старые версии Windows были проблемы с многоуровневые окна, но большинство из них были решены с введением диспетчера окон настольных компьютеров (DWM) в Windows Vista.
Если отказ потока визуализации проявляется как поток визуализации, возможно, является жертвой процесса исчерпания System.OutOfMemoryException некоторых ресурсов. Поток визуализации был вызван в API, который попытался Win32/DX выделить какой-либо ресурс, но потерпел неудачу. Карты WPF возвращают значения, E_OUTOFMEMORY как или ERROR_NOT_ENOUGH_MEMORY в System.OutOfMemoryException . Несмотря на то, что исключение относится к "памяти", сбой может относиться к любому ресурсу, например к обработкам объектов GDI, другим системным ручкам, памяти GPU, нормальной памяти оперативной памяти и т. д.
Замечания по сбоям в распределении ресурсов
Два замечания применимы к System.OutOfMemoryException сбоям и к любому сбою выделения ресурсов.
Корневая причина не может лежать в коде, который сталкивается с ошибкой. Вместо этого может быть другой код в процессе чрезмерного использования ресурса, не оставляя ни одного для обычно успешного запроса.
Если запрос является необычно большим, сбой может произойти, несмотря на ресурс, который выглядит обильным. Это может произойти даже в том случае, если в системе много памяти, если существует запрос на большое System.OutOfMemoryException количество (состоятельной) памяти. Вот реальный пример: плагин Visual Studio, чтобы восстановить свое окно из состояния, сохраненного в предыдущем сеансе. Она неправильно скорректировала разницу DPI между предыдущими и текущими мониторами, которая усугубится с помощью корректировок из нескольких уровней компонентов WPF, WindowsForms и vs window-hosting, чтобы установить размер окна в 16 раз больше, чем должно было быть. Поток визуализации попытался выделить буфер обратного буфера в 256 раз больше, чем необходимо, и не удалось, даже если для ожидаемого выделения было доступно более чем достаточно памяти.
Общие рекомендации
Отключение отрисовки оборудования с помощью значения реестра disableHWAcceleration, рассмотренного в параметре Отключение аппаратного ускорения. Это повлияет на все приложения WPF на компьютере; сделать это только для проверки, связана ли проблема с графическим оборудованием или драйверами. В этом случае можно обойти проблему, программным образом отключив ускорение оборудования на более детальном уровне. Это можно сделать на основе каждого окна с помощью свойства HwndTarget.RenderMode или на основе каждого процесса с помощью свойства RenderOptions.ProcessRenderMode.
Обновите драйверы видео и/или попробуйте другое оборудование видео в проблемной машине(ы).
Обновление до последней операционной системы.
Отключите использование Windows.AllowsTransparency приложения и его использование в Popup.AllowsTransparency приложении.
Я создал клиентское серверное приложение на C++ с помощью Visual Studio.
Как я могу запустить EXE-файл ничего не устанавливая на компьютер?
приложения, построенные с помощью Visual Studio, зависят от Visual C++ Redistibutable (VCRedist). Когда программа связана динамически, то ваши двоичные файлы будут нуждаться MSVCR**.dll (Библиотека Времени Выполнения Microsoft C).
в MSDN есть хорошая статья под названием распространение файлов Visual C++ (для Visual Studio 2008), который утверждает, что есть потенциальные ошибки во время выполнения на случай, если это не требуется библиотека Visual C++ установлено:
- приложение не удалось правильно инициализировать (0xc0000135).
- это приложение не удалось запустить из-за неправильной конфигурации приложения. Переустановка приложения может устранить эту проблему.
- система не может выполнить указанную программу.
- самым простым решением является изменение динамической компоновки библиотек времени выполнения на статическую компоновку. Зайти в свойства проекта и в разделе C / C++ > Генерация Кода вы найдете Библиотека Времени Выполнения. Вам нужно изменить его с Multi-threaded DLL (/MD) to Multi-threaded (/MT) .
- другое возможное решение-сделать убедитесь, что на целевой машине установлена правильная версия распространяемого пакета Microsoft VC++.
но ваше приложение может зависеть и от других библиотек DLL. Если вы хотите узнать, каковы зависимости вашей программы, есть отличная утилита под названием Зависимость Walker, которые помогут вам в этой и многих других ситуациях :)
Справочная информация:
- приложениям C++ необходимы сборки времени выполнения (DLL) для работы на любом компьютере windows.
- обычно эти сборки времени выполнения расположены на C:\Windows\Winsxs справочник.
- все операционные системы windows по умолчанию поставляются с несколькими сборками времени выполнения.
- но если ваше приложение разработано в более новой версии среды сборки во время выполнения, целевой компьютер также нуждается в той же версии времени выполнения существовать там.
- при установке visual studio на компьютер поступает большинство новых версий сборок времени выполнения.
Soloution: Наконец, в любом случае целевой компьютер должен иметь точные сборки времени выполнения. Есть несколько способов сделать это (для более подробного поиска в google каждый).
- статически связать сборки времени выполнения с вашим приложением (хлопотно для большого приложения).
- установить перераспределение C++ среда в целевом компьютере (самый простой способ).
- создание проекта установки для развертывания во время выполнения на целевом компьютере при установке приложения. (Неплохо)
- развертывание сборок времени выполнения в качестве частных сборок (professional) см. здесь для более подробной информации
условия:
Я не видел эту конкретную ошибку раньше, обычно это ошибка вокруг отсутствующей DLL (Windows redistributable). Предполагая, что на самом деле нет проблем с конфигурацией, у вас есть два варианта:
1) измените режим компиляции с многопоточного DLL на многопоточный. Это можно сделать из раздела c++ свойств проекта в разделе генерация кода. В многопоточном режиме ваш двоичный файл будет статически связан с распространяемым Windows. Это, вероятно, что ты хочешь.
2) Установите распространяемый windows на целевой машине. Это, вероятно, не нормально b / c вы заявляете, что не хотите ничего устанавливать на целевой машине.
предупреждение о опции 1, разные версии windows имеют разные версии распространяемого. Можно столкнуться с узкоспециализированной средой, в которой статически связанная программа будет вести себя не так, как ожидалось.
я развернул свою программу в выпуске вместо отладки, и exe теперь работает на другом компьютере
Похоже, вам не хватает некоторых DLL-файлов. Обязательно скопируйте соответствующие dll вместе с exe.
Читайте также: