CC.Net 访问被拒绝错误
我将 CruiseControl.Net 设置为我的持续集成环境。 我一直致力于将 Visual Studio 2008 Web 部署项目添加到我的解决方案中，但我收到了一个奇怪的“访问被拒绝”错误，而且我不明白为什么。
我的服务器上有 CC.Net 在自己的帐户下运行，该帐户是管理员组的成员，因此 CC.Net 服务应该有权访问它所需的所有内容。 问题是当我从 Web 界面触发构建时，构建失败并出现错误：
C:\程序文件 (x86)\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5)： 错误：访问被拒绝。
该行的特定任务是“CreateVirtualDirectory”任务，用于为我的 asp.net 应用程序创建 IIS 虚拟目录。
奇怪的是，如果我在以与 CruiseControl 服务运行时完全相同的用户帐户运行的构建服务器上打开命令提示符，并运行我的构建脚本，一切都会成功构建 - 包括创建 IIS 虚拟目录。 仅当通过 Web 界面启动构建时才会失败。
我不明白两者之间有什么区别，因为大概它们都以具有相同权限的同一用户身份运行。
建议？
I have CruiseControl.Net setup as my continuous integration environment. I've been working on adding a Visual Studio 2008 Web Deployment Project to my solution but I'm getting a weird "access denied" error and I can't figure out why.
I have CC.Net running under its own account on my server which is a member of the administrators group, so the CC.Net service should have access to everything it needs. The problem is when I trigger a build from the web interface the build fails with the error:
C:\Program Files
(x86)\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5):
error : Access is denied.
The particular task on that line is the "CreateVirtualDirectory" task to create an IIS virtual directory for my asp.net application.
What's weird is if I open a command prompt on my build server running as the exact same user account the CruiseControl service is running as and run my build script everything builds successfully - including the creation of the IIS virtual directory. It's only when a build is initiated through the web interface that it fails.
I don't understand what the difference is between the two since presumably they are both running as the same user with the same privileges.
Suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它尝试创建的虚拟文件夹是否可能已经存在？ 另一个想法 - 当您从命令行运行时，您可能有 CC.Net 没有的不同环境变量或驱动器映射？
Is it possible that the virtual folder it is trying to create already exists? Another thought - when you run from a command line, it is possible you have different environment variables or drive mappings that CC.Net wouldn't have?