Как я могу создать приложение .Net, которое распространяется как отдельный и автономный файл / сущность (без установщика)? - PullRequest
1 голос
/ 23 февраля 2012

В настоящее время у меня есть VBScript «приложение» для поддержки для отправки клиентам для запуска, а затем клиент отправляет обратно HTML-файл с результатами.Для сравнения: выходные данные похожи на Syscomp.exe из Absolute Dynamics , за исключением того, что у меня есть один файл .vbs и отсутствует функция сравнения.

Проблема: требования к этому инструменту поддержки постоянно меняются, а сфера его применения расширяется - я считаю, что он слишком большой, чтобы VBScript больше не был подходящим инструментом.В идеале - мой новый инструмент будет иметь механизм для настройки.Например, вместо того, чтобы мне приходилось жестко кодировать все требования / что искать, мог бы быть файл конфигурации, такой как App.config, или, что еще лучше, файл XML с моей собственной схемой разметки, которая может бытьпоставляется как часть приложения для каждого клиента.Примечание: мне не требуется «никакой установки», потому что это будет постоянно меняться, и установщик сделает его гораздо менее гибким;мы не будем просить клиентов устанавливать каждый раз, когда отправляем это.

мое желаемое решение: Мне нужно перейти на платформу более общего назначения..Net идеально подходит, потому что мы уже являемся магазином .Net.Хотя если с .Net я не могу придумать решение для распространения таким же образом, как я уже использую текущий VBScript (единый объект), то я рассмотрю другие среды программирования общего назначения, если они будут упомянуты.

Что я пробовал:

  • DotNetZip, благодаря помощи Cheeso по этому вопросу SO: Запуск приложения .Net из сжатого zip-файлафайл .Я смог использовать это для доставки .Net EXE с поддержкой DLL и App.config, все они были упакованы в самораспаковывающийся ZIP.К сожалению, это не работает в Windows XP, если я что-то упустил.РЕДАКТИРОВАТЬ: подтвердил, что это ограничение Windows XP и Windows Vista, а не DotNetZip. Мне нужно мое решение для работы на XP (многие клиенты имеют XP или фермы Windows 2003 Server)

  • 7Zip - не отвечает моим потребностям, потому что я не могу добавить .config к архиву .7z после того, как я «собрал» свое решение.Я смог добавить файлы в SFX, созданные в DotNetZip, просто переименовав его в «.zip», добавив новый .config, а затем удалив расширение .zip.

  • NBox не будет работать, поскольку упаковка любого файла конфигурации (например, app.config) должна быть частью моего процесса сборки.Мне нужен конфиг, который я могу просто «вставить» после / вне процесса сборки в любой момент, и он будет частью конечного продукта, который будет доставлен

  • КофеCup Zip Wizzard Не имеет возможности распаковать файлы без вмешательства пользователя.Также не позволяет запускать после распаковки EXE

  • Zip Installer от NirSoft .Не соответствует моим требованиям, поскольку он по-прежнему запрашивает конечного пользователя, куда устанавливать файлы.

  • ZIP 2 Secure EXE .К сожалению, это тоже не сработало, хотя я не могу вспомнить, каков был недостаток

  • NAR .это не сработало, потому что для этого требуется установка.Кроме этого, это, вероятно, сработает.

вопросы:

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

Требования:

  • должно быть одной сущностью (например, EXE или ZIP))
  • должен поддерживать хотя бы один файл конфигурации, поддерживать DLL и т. Д. «Надежное» приложение. Редактировать: например, после того, как мой код собран, он может быть заархивирован как самораспаковывающийся ZIP. Любой может «настроить» его через XML-конфигурацию, затем переименовать .exe в .zip, добавить свою конфигурацию и отправить его вместе.
  • Должно работать в XP и вперед. Изменить: Мы предполагаем, что .Net runtime был установлен (по крайней мере v3.5)

1 Ответ

4 голосов
/ 23 февраля 2012

По сути, вы не можете поддерживать XP с приложением .net без каких-либо внешних «вещей» - XP не поставляется с какой-либо версией .net, установленной в стандартной комплектации, поэтому вам может потребоваться, чтобы пользователи установили среды выполнения .net до того, какприложение может работать.С другой стороны, если вы используете .net 4.0, то при запуске программы она сообщит пользователю, что ему нужна среда выполнения .net 4, а не просто сбой, как это было в предыдущих приложениях .net.

Если предположить,то, что однажды предустановка .net в порядке, тогда есть много вариантов:

Вы можете поместить весь свой код в один проект и, таким образом, собрать одну отдельную сборку (.exe)

В качестве альтернативыЕсли у вас есть много библиотек DLL, вы можете использовать инструмент, такой как ILMerge, чтобы объединить их все в один .exe, прежде чем отправлять его, или вы можете встроить библиотеки DLL как ресурсы данных в .exe, а затем использовать события AssemblyResolve приложения, чтобыВы должны загрузить данные DLL из ресурсов, как это необходимо для системы.Или внедрите dll как файлы данных, а затем «автоматически установите» их (сохраните их на диск рядом с вашим .exe или в GAC), как первое, что ваша программа делает, прежде чем она сделает вызов любому из dll, который она отправляет таким образом.

Другая часть этого заключается в том, что ваше приложение должно быть автономным - любые необходимые ему настройки / предпочтения / ресурсы должны быть установлены самим приложением - например, вы можете прочитать настройки предпочтений изреестра и, если его нет, используйте значение по умолчанию.Если у вас есть XML-файл конфигурации, вставьте его в качестве ресурса и либо прочитайте его непосредственно из ресурсов, либо установите его автоматически при запуске, чтобы ваше приложение было «самоустанавливающимся» и полностью автономным.

...