0

我在 c# .net 中构建了一个 Windows 服务。我添加了 Pre-Build 和 Post-Build 事件以在构建上自动部署我的服务。但有时我得到这个错误：

无法将文件“[CompletPath...]\bin\Debug\Business.Data.dll”复制到“bin\Debug\Business.Data.dll”。该进程无法访问文件“bin\Debug\Business.Data.dll”，因为它正被另一个进程使用。

在 Pre-Build 事件中，我将关闭服务，杀死所有使用 Debug 目录中文件的任务并卸载服务。我在 Pre-Build 事件中运行的 .bat 中有代码：

SET executionPath=%~dp0
SET serviceName=%1
SET frameworkPath=%2
SET targetServicePath=%3
SET targetBinPath=%~4
set targetBinPath=%targetBinPath:~0,-2%

net stop %serviceName%
powershell -NonInteractive -executionpolicy Unrestricted -file "%executionPath%\unlockfiles.ps1" "%targetBinPath%"
%frameworkPath%\installutil.exe /u %targetServicePath%

Exit /b 0

在我正在安装和启动服务的构建后事件中，即使这不是问题，也有代码，因为我在构建时遇到了错误，所以构建后事件没有执行。

SET serviceName=%1
SET frameworkPath=%2
SET targetServicePath=%3

%frameworkPath%\installutil.exe /ShowCallStack %targetServicePath%
net start %serviceName%

我并不总是有问题。我通常在第一次构建时遇到问题，我正在清理解决方案，再次构建并且通常它在此之后工作。

4

2 回答 2

1

如果我是你，我会把这些过程分开。您无需卸载服务即可更新文件。

除了在构建完成后移动一些文件之外，我不是构建前/构建后事件的忠实粉丝。

我使用 xcopy /y /c "$(TargetPath)" "要复制到的位置"

如果记忆有用，我什至实际上不必停止服务来更新 dll，但是您可能需要在执行 xcopy 命令之前在后期构建中停止服务。

于 2013-04-30T10:51:20.470 回答
0

如果我处于您的情况，我会开始采用更面向团队的解决方案。

我会花一些时间使用Team City 之类的工具设置持续集成系统（此工具可免费用于多达 20 种构建配置。我真的对 JetBrains 的所有内容进行了评价。

然后，每次您的团队中的一个为服务签入新的源代码时，构建系统（Team City）都会自动检测到它，并且会触发一组新的构建。

您可以有一个针对代码运行单元测试的调试版本，一个发布版本，其中还包括一个WiX 项目，然后还为该服务构建一个安装程序。

完成这些过程后，您可以将其配置为将安装程序弹出到您网络上的已知位置，然后它还可以向您团队中的所有开发人员发送电子邮件，通知他们有新版本的服务可供安装。

WiX 是一个非常成熟的安装创作工具，被微软用于他们的许多产品。该工具集有很多支持，将使您的整个过程更加紧凑、可重复和可预测。

完成所有这些需要一些时间，但确实值得付出努力。

于 2013-05-01T20:50:14.960 回答