【问题标题】:Puzzling differences in behavior between console and web apps控制台和 Web 应用程序之间令人费解的行为差异
【发布时间】:2015-05-20 18:07:59
【问题描述】:

我在 Web API 应用中有一段代码:

private Stream ConvertWorkBookToStream(WorkBook workBook)
{
    var tempFileName = Path.GetTempFileName();

    // The following line throws a NullReferenceException
    workBook.write(tempFileName);

   // Remainder elided for brevity
}

workBooktempFileName 都不是 null

一时兴起,我将应用程序池更改为在域管理员帐户下运行,以消除任何权限问题(因为我最近观察到我的机器上出现了一些普遍的问题)并重新运行它。抛出了同样的异常。

然后我创建了一个控制台应用程序并将方法逐字复制到应用程序中并运行它。 没有抛出异常。

现在,值得注意的是,就在昨天,我遇到了关于 File.Exists 的类似令人费解的行为。

考虑以下调用:

var exists = File.Exists(@"\\myshare\\myexistingfile.ext");

假设路径指向一个实际存在的文件:

  • 在网络应用下,exists 返回false在我的机器上
  • 在控制台应用程序中,同样的操作返回true

我的同事正在经历相反的行为。

谁能解释一下?我有点束手无策。

【问题讨论】:

  • 乍一看肯定会怀疑一些奇怪的权限问题。假设 Web 应用程序在 IIS 下运行,关联的应用程序池的身份有什么特殊或不寻常的地方吗? (例如,考虑可能阻止遍历它所认为的基于网络的资源的身份)
  • 堆栈跟踪是什么?调试的时候,能看出哪一个是空的吗?
  • 检查从 Path.GetTempFileName 返回的结果是否与控制台应用程序和 Web 应用程序不同。 Windows 可能在跟你开玩笑。
  • ARRRRRRRRRGHHHHHH 当然。不同用户上下文的不同临时文件夹。 &)(&(*%&*%) :) 很高兴你解决了。
  • @DavidW:Awww。如果我是一个更好的人,我会送你一个慰问纸杯蛋糕。但这是残酷的编码。 >=)

标签: c# .net web


【解决方案1】:

检查 Path.GetTempFileName 的返回是否与控制台应用和 Web 应用不同。 Windows 可能会和你开玩笑。我在尝试写入日志文件时遇到了类似的问题。我只是放弃了,将它们放在与我的 Web 服务相同的目录中。

【讨论】:

    【解决方案2】:

    在您的 IIS 身份验证设置中,您是否只启用了匿名身份验证?如果我没记错的话,匿名身份验证会模拟具有受限权限的 IUSR 帐户。

    【讨论】:

    • 我们确实启用了匿名身份验证,但这是设计使然。这是一个 REST API,我们的客户向我们传递了一个身份验证令牌。所有请求都是匿名的,我们对每个请求都验证令牌。因此,我们使用应用程序池标识。事实上,如果你观察任务管理器中运行的 w3wp.exe 进程,你可以看到它是在我本地机器上的域管理员帐户下运行的。 (并不是说它不是在模仿别人,只是说。)
    • 我觉得有趣的是你的同事有相反的问题:)。您的控制台应用程序使用什么帐户?还有网络路径\\myshare\\myexistingfile.ext,在运行cmd net use 命令时该路径是否位于?
    • 它在我的本地用户帐户下运行。如果我的同事运行相同的控制台应用程序,它会在他们的本地用户帐户下运行。相反的行为。
    • 一个想法 -> 会不会是您在本地帐户下安装了共享,而您的同事根本没有这样做,因此出现了相反的行为?我实际上只是在猜测,因为我不确定 Windows 在安装共享时如何处理用户凭据。使用本地路径时 WebApi 是否正常工作?运行 cmd net use 命令时,您的共享是否位于?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2022-11-09
    • 1970-01-01
    • 2010-10-19
    • 2012-10-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多