小编Hex*_*xed的帖子

我正在致力于从旧的手动实现的 ci/cd 解决方案到 Azure DevOps 的管道迁移。我仍在重用一些预构建的函数/流程。

例如。就像他们如何将所有解决方案打包为工件一样。

我试图尽可能减少代码更改。

构建管道创建 ClickOnce 包.zip。

然后在发布阶段，myapp.exe.config应用程序文件中的内容通过 XML-Document-Transform 进行转换。此外，应用程序清单<ApplicationName>.application也是通过 Powershell 手动编辑的。<deploymentProvider codebase="http://1.1.1.1/samplefolder/myapp.application" />根据要部署到的环境/路径，发布时会发生变化。

申请清单

<asmv1:assembly ...>
<deployment ...>
    <subscription>
      <update>
        <beforeApplicationStartup />
      </update>
    </subscription>
    <deploymentProvider codebase="http://1.1.1.1/samplefolder/myapp.application" />
</deployment>
</asmv1:assembly>

现在我明白这种方法需要对整个包进行重新签名。他们有一个自定义.exe 文件来重新签名整个包（不是mage.exe）。不幸的是，我无法重复使用上述可执行文件来重新签名。

我所拥有的只是他们的证书指纹。但我不知道该怎么办。

问题：

1. 重新签署包裹还有哪些其他选择？
2. 有一个更好的方法吗？我是否需要为此解决方案执行另一个构建步骤？

我有一个位于桌面上的控制台应用程序.我已将其设置为计划任务,每20分钟无限期运行一次.我已经关闭了自动睡眠/休眠状态.然后我打开电脑并锁定桌面周末(2-3天).

我的控制台应用程序是在每次捕获异常时通过电子邮件发送给我的.当我退回时,检查我的收件箱收到了几封包含的错误电子邮件

访问路径'C:\ WINDOWS\system32\myLogs \'被拒绝.

似乎我的控制台应用程序是从System32不是从我的运行Desktop.

问:为什么它表现得像？

这是我创建myLog文件夹路径的字符串

var logpath = Directory.GetCurrentDirectory() + Properties.Settings.Default.LogPath;

这将检查文件夹是否存在,如果不存在则创建新文件夹.

if (!Directory.Exists(logpath))
   Directory.CreateDirectory(logpath);

我相信在检查/创建文件夹时触发了错误.我的应用程序应该myLog在与控制台应用程序相同的目录中创建该文件夹.

问:为什么它从System32文件夹运行？