【问题标题】:How do I deploy two ClickOnce versions simultaneously?如何同时部署两个 ClickOnce 版本?
【发布时间】:2010-12-17 18:43:50
【问题描述】:

我希望能够为我的应用程序提供一个测试 ClickOnce 服务器,用户可以在其中并行运行生产版本和测试版本。这可能吗?

我首先尝试在AssemblyInfo.cs 中使用以下内容,并且还更改了 ClickOnce 部署中的名称,尽管这一切都是用测试版本覆盖用户的生产版本。同样,当他们回到生产服务器时,它也会这样做。

#if DEBUG
[assembly: AssemblyTitle("Product Name - Test")]
#else
[assembly: AssemblyTitle("Product Name")]
#endif

我想我还应该澄清一下,这两个部署位置彼此不同,并且位于不同的服务器上。

更新

我还尝试根据调试模式为清单设置 GUID,但它再次不起作用(下面使用了虚拟 GUID)。

#if DEBUG
[assembly: Guid("AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA")]
#else
[assembly: Guid("BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB")]
#endif

这两者有什么区别?似乎安装程序将它们视为两个独立的程序,因为我得到了每个程序的安装确认。虽然,当我安装第二个时,“添加/删除程序”只看到后者,虽然前者仍在磁盘上,当我稍后重新安装它时,它只是简单地运行,但随后添加/删除程序切换回到原来的名字。

【问题讨论】:

  • 在回答您关于 clickonce 应用程序身份的第二个问题时,这与程序集 guid 无关,而与您的发布所签署的密钥(pfx 文件)有关
  • @Rob 这很有趣,所以如果我有多个使用相同密钥签名的应用程序,这会导致 windows 认为它​​们是同一个应用程序吗?这对我来说似乎是一个严重的缺陷。
  • 不,这不是问题。我安装了 7 个使用相同密钥签名的应用程序,这不是问题。

标签: c# .net deployment clickonce


【解决方案1】:

在至少配置一次项目以发布 Click Once 应用程序后,您必须手动编辑 csproj。

将一些 Click Once 相关属性从 <PropertyGroup> 移动到 <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> 属性组,并将它们复制到 <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> 属性组下。

要复制的属性是ApplicationRevision(仅当您想要单独的修订计数器时)、PublishUrlProductNameSuiteName(需要最后两个才能区分目标机器上的配置) .您还必须覆盖 AssemblyName 属性(不要将其从第一组中删除)。

如果您希望能够在任何配置下调试您的项目,您还必须在覆盖AssemblyName 属性的每个组中添加StartActionStartProgram 属性。

在为这些属性提供足够的(即不同的)值后,您将能够发布这两种配置,无需修改您的项目,只需选择所需的配置即可。但是请注意您必须在不同配置的发布之间卸载您的项目,否则 Visual Studio 会弄乱您的参数。

之后,您还可以在同一台目标机器上安装这两个版本。

【讨论】:

    【解决方案2】:

    Peter Mortensen 的两个项目场景的变体。我想要开发、客户测试和客户发布。就我而言,我希望客户测试提供一些视觉线索,表明它是测试的,而不是现场的(例如标题中的“测试”和不同的视觉主题)。

    我发现拥有两个解决方案和两个存根项目是最简单的。每个项目都在自己的目录中,有自己的存根 program.cs、app.config 和 assemblyinfo.cs。

    在开发/测试解决方案中,调试配置用于开发,发布配置用于客户测试。我使用 SlowCheetah 为后者转换了 app.config。

    在客户发布解决方案中,我只需要发布配置。

    【讨论】:

      【解决方案3】:

      这听起来可能有点蹩脚,但最简单的方法是在您的解决方案中包含两个 EXE 项目。其中每个的 Main 方法只会调用原始 EXE 项目中的 Main 方法(您将刚刚切换为 DLL 文件)。

      这意味着每个 EXE 项目都可以有自己的 ClickOnce 发布设置,以及自己的 app.config 文件。这意味着生产版和测试版有不同的连接字符串。

      您的另一个选项(似乎最有意义的选项)是使用MageUI.exe 手动构建 ClickOnce 文件,这样您就可以在每次运行该工具时选择不同的配置文件并发布位置。还有一个命令行版本 (Mage.exe),因此理论上您可以自动执行此操作。

      但是,我们发现包含两个“跑步者”项目的解决方案要简单得多。我建议你先试试。

      【讨论】:

      • 我可以看到两个存根 exe 的简单性,尽管我也可以将其视为维护两组配置等的负担。我会先看看我如何使用 mage 然后尝试后者。我可以看到使用两个存根 exe 维护用户设置真的很痛苦。
      • 我认为你对两个存根的想法是正确的,这听起来不合逻辑,但确实比法师更混乱,但正如前面提到的,我担心我会找到我的团队因配置差异而陷入困境,我们可能需要通过构建过程合并来自每个项目的 app.config 来管理这个问题,ick
      • 这可能会有所帮助:stackoverflow.com/questions/132885/…
      • 关于使用命令行版本的 mage 自动部署的注意事项。它工作正常,但它是 mageui 的一个子集。有很多你不能用命令行法师做的事情,比如设置你的应用程序图标。
      • 为了解决用户设置的重复问题,我在原始项目中创建了第二个设置文件,其中包含需要在其他项目中覆盖的设置。将文件的 Access Modifier 更改为 Public 后,您可以在其他项目中创建 app.config 文件以覆盖设置。
      【解决方案4】:

      我手动编辑了.csprojdebug/release 指定不同的产品名称。

      <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
          ...
          <PublishUrl>publishbeta\</PublishUrl>
          <InstallUrl>http://www.softwareabc.com/download/beta/</InstallUrl>
          <ProductName>Software ABC Test</ProductName>
          <AssemblyName>SoftABCTest</AssemblyName>
          <ApplicationIcon>Resources\Test.ico</ApplicationIcon>
        </PropertyGroup>
        <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
          ...
          <PublishUrl>publish\</PublishUrl>
          <InstallUrl>http://www.softwareabc.com/download/</InstallUrl>
          <ProductName>Software ABC</ProductName>
          <AssemblyName>SoftABC</AssemblyName>
          <ApplicationIcon>Resources\Application.ico</ApplicationIcon>
      </PropertyGroup>
      

      需要注意的是,如果您在调试/发布之间切换,Visual Studio 2010 不会对此进行更新。它仅在加载解决方案时生效,因此请确保切换调试/发布,然后关闭并重新打开解决方案。

      【讨论】:

      • 当我尝试这个时,PropertyGroup ClickOnce 条件实际上被覆盖了。
      • 我从未见过它被覆盖,但绝对不要通过 Visual Studio 中的项目 GUI 更改任何构建设置,这可能会覆盖它。
      • 如果您使用一种配置发布,请切换到另一种并关闭解决方案 - VS 会询问您是否要保存项目(因为它确实覆盖了这些属性)。选择“否”,然后重新打开解决方案。在这种情况下,您的属性不会被覆盖。显然正因为如此,这是一个脆弱的解决方案,但如果你小心的话,它确实有效。
      • @StevenPena - 是的,但这是你试图通过自动化部署来避免的 - 需要在每次发布之前检查发布、安装和更新 URL。你怎么能保证其中一位开发人员在某些时候不会保存项目属性选项卡,即使是错误的?必须有更可靠的解决方案。 app.config 问题很容易解决 - 您只需为每个环境添加一个 .config 文件,例如 app.config.devtest、app.config.uat、app.config.prod 和预构建命令:xcopy / y "$(ProjectDir)app.config.$(ConfigurationName)" "$(ProjectDir)app.config"
      • @ChrisW。是的。这不是一种自动化的方法。我在这里澄清了建议的答案,这是一种手动方法-但确实提出了该问题的解决方案(原始问题中没有任何关于自动化的内容)。您提出的问题是不同的问题,而不是这里提出和回答的问题。我建议您创建一个更具体的自动化问题。
      【解决方案5】:

      ClickOnce: Concurrent versions 解释了如何做到这一点。

      【讨论】:

      • 谢谢罗宾,似乎是一个相当简单的方法,虽然有一些事情要记住改变/改变回来,有没有一种简单的方法可以做到这一点,也许一个 MSBuild 文件可以为我做到这一点会很简单地导入现有的 csproj 文件,但设置 AssemblyName 等?我发现您无法在属性组中更改这些内容,如果您尝试,它们会被忽略。
      • 您只需更改 3 件事。部署 URL、程序集名称和产品名称。我们使用源代码控制,所以我只搁置一组这些更改,并在需要时取消搁置它们。
      • @RobinDotNet 虽然理论上可以回答这个问题,it would be preferable 在这里包含答案的基本部分,并提供参考链接。
      • 基于该 vlog 1. 为“测试”版本创建一个源代码控制分支,在主 2 上使用“实时”。在 Visual Studio 2017 (VS) 中的“发布...应用程序”下添加“测试”后缀添加到“程序集名称” 3. 在 VS 中的“发布...发布”下将“测试”后缀添加到“发布文件夹位置”和“安装文件夹 URL” 4. 在 VS 中的“发布.. . Publish... Options...' 将“Test”后缀添加到“Product name” 5. 更改应用程序使用的任何文件或资源(即日志文件) 6. Publish 7. 测试完成后合并“测试'分支到'master'并反转步骤。
      【解决方案6】:

      观看关于并发版本控制的简洁视频:ClickOnce: Concurrent versions

      【讨论】:

      • 基于该 vlog 1. 为“测试”版本创建一个源代码控制分支,在主 2 上使用“实时”。在 Visual Studio 2017 (VS) 中的“发布...应用程序”下添加“测试”后缀添加到“程序集名称” 3. 在 VS 中的“发布...发布”下将“测试”后缀添加到“发布文件夹位置”和“安装文件夹 URL” 4. 在 VS 中的“发布.. . Publish... Options...' 将“Test”后缀添加到“Product name” 5. 更改应用程序使用的任何文件或资源(即日志文件) 6. Publish 7. 测试完成后合并“测试'分支到'master'并反转步骤。
      【解决方案7】:

      我一直这样做。我什至在我的应用程序中有一个屏幕,可以更改特定用户将获得的版本。而且我没有在应用程序方面做任何棘手的事情,所有的魔法都在托管 ClickOnce 文件的 Web 服务器上。

      看看我朋友写的文章,Fine Grained Versioning with ClickOnce。它解释了我们是如何做到的。

      【讨论】:

      • 我实际上是在尝试通过不同的版本允许同一应用程序的两次单击安装,一个是生产树版本,另一个是在另一个更新服务器上,即测试树。
      • 在另一台服务器上......是的,听起来你必须玩 MageUI。
      • 这可以在 Linux 上运行吗(例如,网络酒店上的 Apache)?或者甚至在网络酒店上使用 IIS?
      • 我不明白为什么不这样做。归根结底,ClickOnce 只是下载一两个文件。它不知道也不关心您使用什么来托管文件。
      【解决方案8】:

      尝试在属性窗口的“应用程序”选项卡中更改程序集名称。

      【讨论】:

      • 不幸的是,这只解决了部分问题,客户端仍然认为它是同一个应用程序但名称不同,因此任何ApplicationSettingsBase对象的数据存储都被共享,测试版本最终损坏生产版本。
      猜你喜欢
      • 2011-02-21
      • 1970-01-01
      • 2021-09-28
      • 1970-01-01
      • 2011-02-07
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-12-14
      相关资源
      最近更新 更多