在 C# Web 服务中执行批处理文件
我正在尝试在 C# Web 服务中执行批处理文件。我确信批处理文件没有问题。我面临的问题是批处理文件只会在调试模式下执行。当我与客户端计算机连接时,它不会产生错误,也不会被执行。我确信连接没有任何问题,因为我可以成功地将某些内容从客户端发送到网络服务。
代码如下:
try
{
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo.FileName = "C:\\mybatch.bat";
proc.StartInfo.UseShellExecute = true;
proc.Start();
}
catch (Exception e)
{
return e.ToString();
}
Visual Studio 在管理员模式下运行,但 cmd.exe 在 (myUser) 模式下运行,但我已授予每个用户完全访问权限。我不知道这是否有问题。如果没有,我应该在代码中添加一些东西吗? :(
请告诉我问题的可能原因以及解决方法。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
Web 服务不在“普通桌面”中运行...它具有不同(=更少)的权限/权限,例如它们通常无权访问共享...您可以与您的用户一起运行 Web 服务帐户(巨大的安全风险!)或者应该重新考虑您的设计,因为从 Web 服务运行批处理文件通常不是 Web 服务所做的事情...
如果您确实需要这样做,请尝试
查看 http://msdn.microsoft.com/en-us/library/system .diagnostics.processstartinfo.aspx
A web service is not running in the "normal desktop"... it has different (=less) permissions/rights, for example they usually don't have access to shares... you can either run the web service with your user account (BIG security risk!) or should reconsider your design since running batch files from web services isn't usually something web services do...
IF you really need to do this try
see http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.aspx
当某些东西在调试模式下工作但在发布模式下失败时,这是非常令人沮丧的!为了解决运行时差异,我会考虑使用 SysInternals 的免费 ProcMon 工具:http: //technet.microsoft.com/en-us/sysinternals/bb896645
下载并运行 ProcMon 以捕获所有注册表和文件访问。运行后,以调试模式访问您的网站,并通过 Web 服务成功执行批处理文件。在 ProdMon 中,停止捕获(按 CTRL-E 开始和停止捕获),然后按 CTRL-F 搜索“mybatch.bat”。
您应该找到多行——注意关联的进程(可能是“w3wp.exe”),并注意每行的操作、路径和结果。您可以过滤结果 - 只需右键单击进程名称并选择“包含 w3wp.exe”。
当您准备好查看发布失败情况时,请清除跟踪 (CTRL-X),将网络服务器置于发布模式,然后再次启动跟踪。现在点击您的网络服务...一旦失败,请停止您的跟踪 (CTRL-C) 并查看它以查看失败时到底发生了什么。一旦了解了这一点,您将能够专注于解决该问题 - 调试和发布之间的具体区别。答案可能就在 Yahia 指出的文档中: http ://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.aspx
祝你好运,并告诉使用你发现的内容!
It's very frustrating when something works in Debug mode, but fails in Release! To sort out the runtime differences, I'd consider using the free ProcMon tool from SysInternals: http://technet.microsoft.com/en-us/sysinternals/bb896645
Download and run ProcMon to capture all registry and file access. With it running, hit your website in Debug mode and sucessfully execute your batch file through the web service. The in ProdMon, stop capturing (press CTRL-E to start and stop capture) and the press CTRL-F to search for "mybatch.bat".
You should find multiple lines--pay attention to the associated process (likely "w3wp.exe"), and notice the Operation, Path and Result of each line. You can filter your results -- just right-click on the Process Name and chose "Include w3wp.exe".
When you're ready to see the Release fail case, clear your trace (CTRL-X), put your webserver in Release mode, start your trace again. Now hit your webservice...once it fails stop your trace (CTRL-C) and review it to see what exactly if failing. Once you know that, you'll be able to focus on resolving that issue-the specific difference between debug and release. It's likely the answer will be in the documentation that Yahia pointed to: http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.aspx
Good luck and tell use what you find!
正如 Yahia 上面指出的,您的问题与安全权限有关。当在 VS 中通过调试运行时,您的 Web 服务的常规权限会提升。
您可以开发一个轻量级 Windows 服务,它将在 Web 服务主机上运行(您可以将它们放置在不同的计算机上,只要它们能够访问某些共享资源 - 参见下文)。现在,这个 Windows 服务自然会拥有扩展的权限,因此它可以随时运行任何进程。
至于如何利用两个兄弟服务之间的通信,我认为您有几种选择。我脑海中立即浮现的第一个想法是使用位于共享位置的文件。当 WS 收到请求时,它会将该请求写入该共享上的文件中。 Windows 服务有一个轮询计时器来检查该位置是否有新作业,或者它可以使用 FileSystemWatcher 以获取事件通知。
As Yahia pointed up above, your issue is related to security permissions. When run via Debug within VS, your web service's regular permissions are elevated.
You can develop a lightweight Windows Service which will run on the web service host machine (you can place them on different machines, as long as they have access to some shared resources - see next). Now, naturally, this Windows Service will have extended permissions, so it could run any process at any time.
As in how to leverage communication between the two brother services, I reckon you have a few options. First one that pops in my head right away is using files located on a shared location. When the WS receives a request, it writes down that request in a file on that share. The Windows service either has a poll timer to check for new jobs in that location, or it can use a FileSystemWatcher to get notified by events.