通过PowerShell的或批处理序列symstore的执行 [英] Serialize execution of symstore via Powershell or BATCH

问题描述

我们正在努力整合的一个步骤到我们的持续集成（CI）服务器（CruiseControl.NET）。我们要注册我们的构建过程中产生到Microsoft符号服务器调试符号 *。PDB 。正如微软实施，符号服务器的目录结构的Visual Studio使用找到 *。对于C ++ / C＃可执行文件PDB 调试符号。微软提供了一个命令 symstore 这需要在一个目录调试符号，并填充适当的中心象征的存放目录。

We are working to integrate a step into our continuous integration (CI) server (CruiseControl.NET). We want to register the debug symbols *.pdb generated from our build process into a Microsoft Symbol Server. As implemented by Microsoft, a symbol server is a directory structure Visual Studio uses to find the *.pdb debug symbols for C++/C# executables. Microsoft provides a command symstore that takes debug symbols in one directory and populates the central symbol store directory as appropriate.

麻烦的是 symstore 明确指出它不是安全的同时运行。

The trouble is symstore explicitly states it is not safe to run concurrently.

什么样的​​方法和策略，我们才能尝试通过批处理或PowerShell脚本禁止 symstore 命令的并发执行？

What approaches or strategies can we try to prohibit the concurrent execution of the symstore command via BATCH or Powershell scripts?

我们正在方法灵活，但因为我们运行在Windows平台上，BATCH和PowerShell是preferred解决方案。

We are flexible on approach, but because we run on a Windows platform, BATCH and Powershell are preferred solutions.

澄清：

有关我们的用例， symstore 需要从两个不同的CI服务器，这将节省一个共同的网络驱动器上的符号运行的。

For our use-case, symstore needs to be runnable from two different CI servers which will save the symbols on a common network drive.

资源：

symstore ::
的http://msdn.microsoft.com/en-us/library/windows/desktop/ms681417(v=vs.85).aspx

symstore:: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681417(v=vs.85).aspx

推荐答案

您可以使用锁定的文件作为一个简单的信号序列化事件。当标准输出重定向到一个批处理文件的文件，它建立在该文件的独占写锁。没有其他方法可以打开进行写访问同一个文件。当过程结束后，该锁将自动被释放不管它如何结束（干净的退出，CTRL-C，异常故障等）

You can use a locked file as a simple semaphore to serialize events. When you redirect stdout to a file in a batch file, it establishes an exclusive write lock on that file. No other process can open up the same file for write access. The lock will automatically be released when the process finishes, no matter how it ends (clean exit, CTRL-C, Exception failure, etc)

一个批处理文件，可以尝试到9重定向到一个锁定文件，如果失败，回送，直到成功。在锁定到位symstore命令只运行。非标准文件句柄（流？）是用来使锁不与标准输入，标准输出，或标准错误处理干扰。

A batch file can attempt to redirect 9 to a lock file, and if it fails, loop back until success. The symstore command is only run while the lock is in place. A non-standard file handle (stream?) is used so that the lock does not interfere with stdin, stdout, or stderr processing.

所以，你只需要确保你永远不会symstore直接调用。相反，你总是通过一个批处理脚本调用它。类似如下（serializeSymstore.bat）：

So you just need to make sure you never call symstore directly. Instead you always call it via a batch script. Something like the following (serializeSymstore.bat):

@echo off
setlocal

:loop

:: Save stderr definition and redirect stderr to nul
:: to hide possible redirection error when establishing lock.
8>&2 2>nul (

  %= Attempt to establish the lock and restore stderr =%
  9>"\\centralServer\somePath\symstore.lock" 2>&8 (

    %= If got here then lock is established throughout all commands =%
    %= in this set of parentheses.                                  =%

    %= Execute your command =%
    symstore %*

    %= Save the return code =%
    call set "rtnCd=%%errorlevel%%"

    %= The next command is a very fast way to clear the ERRORLEVEL. =%
    %= We don't want symstore failure to trigger a loop.            =%
    (call )
  )

) || (
  %= If entered here then failed to establish lock.                 =%
  %= Wait 1 second and then loop back to retry.                     =%
  %= Replace with PING delay if TIMEOUT not universally available.  =%
  timeout 1 /nobreak >nul
  goto loop
)

:: Exit with appropriate return code
exit /b %rtnCd%

没有意见，就变成code一点点

Without comments, it becomes a tiny bit of code

@echo off
setlocal

:loop
8>&2 2>nul (
  9>"\\centralServer\somePath\symstore.lock" 2>&8 (
    symstore %*
    call set "rtnCd=%%errorlevel%%"
    (call )
  )
) || (
  timeout 1 /nobreak >nul
  goto loop
)
exit /b %rtnCd%

我发现这个原始而简单的策略是在很多项目中非常有效。我必须承认，我没有测试过锁，并且在远程计算机上释放特性。但我相信它应该是可靠的，只要所有的机器都是Windows。

I have found this primitive and simple strategy to be extremely effective in many projects. I must confess that I have not tested the lock and release characteristics on remote machines. But I believe it should be reliable as long as all machines are Windows.

我所知道的唯一的缺点是没有FIFO队列。如果接收到多个重叠的请求，那么它的抽签随机运气去哪家进程得到下一步要做什么。但进程将被序列化。

The only drawback I am aware of is that there is no FIFO queue. If multiple overlapping requests are received, then it's a random luck of the draw as to which process gets to go next. But the processes will be serialized.

编辑：
我读过四溅位前编辑原来的答案。他质疑说，文件锁定是在远程机器上可靠。我做了一些快速谷歌搜索，确实出现了一些问题与UNC路径文件锁定。如果你遇到问题，你可能有更好的运气重定向到一个文件上的映射驱动器盘符，而不是直接通过UNC路径。这是所有的理论 - 我所做的没有测试。请务必提交到该解决方案前做充分的测试。需要注意的是PUSHD是临时分配驱动器号到UNC路径不知道什么驱动器号可用的便捷方式。 POPD将取消映射驱动器分配。

I've read splattered bits' original answer prior to editing. He questions whether file locking is reliable on remote machines. I did some quick Google searches and there does appear to be some issues with file locking on UNC paths. If you run into problems, you may have better luck redirecting to a file on a mapped drive letter instead of directly through a UNC path. This is all theory - I've done no testing. Please be sure to do adequate testing before committing to this solution. Note that PUSHD is a convenient way to temporarily assign a drive letter to a UNC path without knowing what drive letters are available. POPD will unmap the drive assignment.

这篇关于通过PowerShell的或批处理序列symstore的执行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！