C# 可能愚弄HTTPContext.Current？

我在程序集中有以下代码行：

 HttpContext.Current.Server.MapPath

如果该程序集正在web服务中使用，这将非常有效

但是，如果我把它从web服务中去掉，它显然不会工作，因为HTTPContext不存在

仅仅为了得到目录的相对路径结构，就有可能欺骗httpContext使其认为它存在吗

我的意思是手动创建HTTPContext对象，并为其分配一个基本目录

更新

是否有更通用的方法：HttpContext.Current.Server.MapPath

---

可以在可执行文件中工作，也可以在web中工作的东西？

在我看来，您需要将对HttpContext的调用封装在另一个对象中，然后使用IOC在正确的环境中切换到正确的对象。例如，像IMapPath这样的东西作为您的接口，然后您的实现可以是httpappath或consoleAppmath等。

此类代码是特定于网站的。我想知道为什么它属于商业逻辑

---

最好的解决方案可能是重新考虑此代码，将

HttpContext

从业务逻辑中排除。例如，您可以接受文件路径作为方法参数，而不是在业务逻辑中解析它。

在编写使用HttpContext.Current的单元测试时，我们会做类似的事情。我们有一个名为IHttpContext的接口，它包含我们从正常HttpContext中需要的所有内容。然后，我们没有调用HttpContext.Current，而是使用一个扩展方法（HttpContext.Current.Make（））返回这个IHttpContext接口

在扩展方法中，我们可以决定HttpContext.Current是否可用，如果不可用，则可以手动构建一个“可测试”对象并返回该对象

当然，如果您正在使用IRequest、IResponse等对象，这也会扩展到必须编写它们，但我认为这是意料之中的事情，即“获取或设置HttpContext对象”。HttpContext有一个公共构造函数，它接受HttpWorkerRequest（抽象，使用SimpleWorkerRequest），您可以完全伪造HttpContext

---

我同意其他人的看法，即您可以重构代码以删除此依赖关系，但在某些情况下，您必须伪造HttpContext。当前内容，在这种情况下，如果您搜索…

则会出现此问题。我不确定这是否有帮助，但我在为asp.net web应用编写一些单元测试时遇到了类似问题。在某个api调用的某个点上，HttpContext.Current.XXXXX正在设置一个不在范围内的属性。我发现答案是在我的单元测试中添加以下属性：

[TestMethod（）]
[主机类型（“ASP.NET”）]
[UrlToTest（“”）]