Подтвердить что ты не робот

Развертывание Clickonce для нескольких сред

У меня есть приложение WPF, которое я хочу развернуть нашим пользователям через ClickOnce. У нас есть четыре среды: тестирование системы, тестирование пользователей, параллельное производство и производство. Каждому нужен другой файл конфигурации с именами серверов и другими вещами, специфичными для среды, поэтому они не могут использовать одну и ту же базу кода. Большая часть кода такая же, но последний пакет будет немного отличаться из-за разных файлов .config.

То, что я нахожу, это то, что мы устанавливаем версию в пользовательском тестировании, скажем, версию 05, затем тестируем, а затем, когда приходит время, чтобы дать им следующую версию, мы должны просто добавить обновленный пакет на пользовательский тестовый веб-сервер, то они могут обновить свою версию, нажав на URL-адрес развертывания. Но когда они это делают, он говорит, что "приложение с тем же идентификатором уже существует", и нам нужно удалить панель управления, чтобы установить версию 06 для установки. Это кажется неправильным, а не точкой clickonce.

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

4b9b3361

ОТВЕТЫ

Ответ 1

Искав какое-то время решение, мне показалось, что последнее, что я придумал, на самом деле так просто:

  • Slow Cheetah для преобразования конфигурационных файлов на основе выбранной конфигурации сборки (например, Debug/Release)
  • Группа свойств для каждой конфигурации сборки с конкретными свойствами проекта click-once (например, ProductName и AssemblyName (для параллельной установки тестовой версии и версии prod), InstallUrl) в файле проекта.
  • Указание дополнительных свойств (например, ApplicationVersion, MinimumRequiredVersion) через msbuild при выполнении /target: publish

Нет необходимости копировать любые файлы конфигурации вручную, так как медленный гепард справится с этим. Пакет click once будет создан в соответствующей папке вывода конфигурации сборки (например, bin/Debug или что-то еще, что у вас есть).

Самое большое преимущество заключается в том, что сборка одинакова для использования Visual Studio или автоматической сборки с использованием msbuild (за исключением нескольких дополнительных свойств, которые являются полностью необязательными). Все, что вам нужно сделать, чтобы добавить дополнительные среды в вашу сборку, это создание новых конфигураций сборки и соответствующих медленных преобразований гепарда и группы свойств в файле проекта.

Вся настройка работает как минимум с .NET 3.5 (не может говорить о более ранних версиях) и позже.

Может быть, это помогает кому угодно. Не стесняйтесь спрашивать подробности.

PS: Группы свойств выглядят так (поместите их после первой группы свойств, которая определяет настройки ClickOnce по умолчанию):

  <PropertyGroup Condition=" '$(Configuration)' == 'Demo' ">
    <AssemblyName>Com.MyApplication.Main.Demo</AssemblyName>
    <InstallUrl>http://demoserver/myapp/</InstallUrl>
    <ProductName>My Application %28Demo%29</ProductName>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Test' ">
    <AssemblyName>Com.MyApplication.Main.Test</AssemblyName>
    <InstallUrl>http://testserver/myapp/</InstallUrl>
    <ProductName>My Application %28Test%29</ProductName>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Prod' ">
    <AssemblyName>Com.MyApplication.Main</AssemblyName>
    <InstallUrl>http://prodserver/myapp/</InstallUrl>
    <ProductName>My Application</ProductName>
  </PropertyGroup>

Ответ 2

Во-первых, вы не можете установить приложение с тем же именем развертывания из двух разных URL-адресов, не сначала удаляя его. ClickOnce использует это для обеспечения безопасности, чтобы убедиться, что кто-то не пытается захватить ваше развертывание.

Во-вторых, чтобы сделать разные сборки, вы можете настроить четыре папки в проекте, по одному с каждым именем. Затем настройте четыре конфигурации сборки (назовите их одинаковыми). Затем настройте команду post-build, которая копирует файлы в папку \bin. Если вы настроите имена папок, чтобы иметь в них конфигурацию сборки, она скопирует все, что будет с этой конфигурацией.

COPY/Y "$(TargetDir)myfile_$(ConfigurationName)\*.*" "$(TargetDir)"

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

Ответ 3

Я пытаюсь сделать то же самое в течение последних двух дней без везения. Мой текущий метод делает следующее:

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj
del c:\Product\app.config
ren C:\Product\systest.config C:\Product\app.config
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="System Test Product";InstallUrl="http://systest.product.temp-uri.org/install/"
ren C:\Product\bin\Release\app.publish systest.app.publish

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj
del c:\Product\app.config
ren C:\Product\usertest.config C:\Product\app.config
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="User Test Product";InstallUrl="http://usertest.product.temp-uri.org/install/"
ren C:\Product\bin\Release\app.publish usertest.app.publish

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj
del c:\Product\app.config
ren C:\Product\parallelprod.config C:\Product\app.config
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="Parallel Prod Product";InstallUrl="http://parallelprod.product.temp-uri.org/install/"
ren C:\Product\bin\Release\app.publish parallelprod.app.publish

msbuild /t:clean /p:Configuration=Release;PlatformTarget=x86 "C:\Product\Product.csproj
del c:\Product\app.config
ren C:\Product\prod.config C:\Product\app.config
msbuild /t:publish /p:Configuration=Release;PlatformTarget=x86;UpdateEnabled=true;UpdateMode=Foreground;UpdatePeriodically=false;MinimumRequiredVersion=2013.2.1086.5496;ApplicationVersion=2013.2.1086.5496;UpdateRequired=true;ProductName="Prod Product";InstallUrl="http://prod.product.temp-uri.org/install/"
ren C:\Product\bin\Release\app.publish prod.app.publish

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