CruiseControl.NET 具有多个 SourceSafe 数据库
我正在尝试配置 CruiseControl.NET，但遇到了 SourceSafe 的问题。当 ccnet 构建时，我收到错误：
找不到 VSS 数据库 (srcsafe.ini)。 将 SSDIR 环境变量设置为 VSS 的 srcsafe.ini 路径 数据库
我知道设置 SSDIR 环境变量可以解决这个迫在眉睫的问题，但是我认为这不是必需的，因为我已在 ccnet.config 文件中指定了它 在我看来，设置环境变量将限制 ccnet 只对所有项目使用一个 SourceSafe 数据库，
我将 ccnet 作为 Windows 服务运行，并使用与登录计算机相同的用户名和密码。
以下是我的 ccnet.config 文件中的源代码控制部分：
<sourcecontrol type="vss">
<ssdir>S:\DotNet\</ssdir>
<project>$/Web/Silverlight/SilverlightFramework</project>
<username>ccnet</username>
<password></password>
<autoGetSource>true</autoGetSource>
<workingDirectory>D:\Build\Projects\SilverlightFramework\WorkingDirectory</workingDirectory>
</sourcecontrol>
预先感谢您
I'm trying to configure CruiseControl.NET and have come across an issue with SourceSafe. When ccnet builds I am getting the error:
No VSS database (srcsafe.ini) found.
Set the SSDIR environment variable to
the path of srcsafe.ini for your VSS
database
I understand that setting the SSDIR environment variable would solve this immediate problem, however I don't believe that this should be necessary as I have specified it in my ccnet.config file. In my mind, setting the environment variable would limit ccnet to only ever use one SourceSafe database for all projects
I am running ccnet as a windows service and is using the same username and password that I would use to log onto the machine.
Below is the sourcecontrol section from my ccnet.config file:
<sourcecontrol type="vss">
<ssdir>S:\DotNet\</ssdir>
<project>$/Web/Silverlight/SilverlightFramework</project>
<username>ccnet</username>
<password></password>
<autoGetSource>true</autoGetSource>
<workingDirectory>D:\Build\Projects\SilverlightFramework\WorkingDirectory</workingDirectory>
</sourcecontrol>
Thank you in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我运行 ccnet 服务的用户似乎没有指定 ssdir 位置的读取权限。
这有点误导，因为我可以使用相同用户名下的映射目录 S:\ 访问该位置，但这可能是由于 Windows 在映射驱动器时存储了缓存的凭据。
It seems that the user I was running the ccnet service as did not have read access to the ssdir location specified.
This was a bit misleading because I could get to the location using the mapped directory S:\ under the same username but presumably this was due to windows having stored cached credentials from when the drive was mapped.