我有在装配此行的代码：可能愚弄HTTPContext.Current？
HttpContext.Current.Server.MapPath
如果在Web服务所使用的装配这个伟大的工程。
但是如果我把它从Web服务中取出，它显然不会工作，因为HTTPContext不存在。
是不是有可能愚弄httpContext认为它存在，真的只是为了获得目录的相对路径结构？
我的意思是手动创建HTTPContext对象，并为其分配一个基本目录？
更新
是否有一个更通用的方法来：HttpContext.Current.Server.MapPath
的东西，可以在可执行文件的工作，有什么东西可以在网上工作吗？
HttpContext.Current“获取或套的HttpContext对象”。而HttpContext有一个公共的构造函数，它接受一个HttpWorkerRequest（抽象的，使用SimpleWorkerRequest），你可以完全伪造HttpContext。
我同意其他人，你可以重构代码以消除这种依赖关系，但也有情景时，必须假的HttpContext.Current的东西，在这种情况下，这个问题会出现，如果你搜索...
这听起来像你需要将对另一个对象的HttpContext的调用包裹起来，然后你可以在正确的环境中使用IOC切换出正确的对象。例如。像IMapPath作为您的接口，然后您的实现可能是HttpMapPath或ConsoleAppMapPath等
这样的代码是特定于网站。我创建它为什么属于商业逻辑。
可能重新考虑这段代码将排除HttpContext从业务逻辑将是最好的解决方案。例如，您可以接受文件路径为方法参数的路径，而不是在业务逻辑中解析它。
在编写使用HttpContext.Current的单元测试时，我们做了类似的事情。我们有一个名为IHttpContext的接口，它包含我们需要的来自普通HttpContext的所有东西。然后，而不是调用HttpContext.Current，我们有一个扩展方法（HttpContext.Current.Make（）），它返回这个IHttpContext接口。
在扩展方法，我们就能够决定HttpContext.Current是否可用，如果不是的话，那么我们可以手动建立一个“可测试的”对象，并返回。
当然，这延伸到具有写IRequest，IResponse等对象，如果你使用的是他们，但我认为这是可以预料的
不知道这是否会有所帮助，但在为asp.net web应用程序编写一些单元测试时，我遇到了类似的问题。在其中一个API调用中，某个属性由HttpContext.Current.XXXXX设置，这不在范围之内。我找到了答案是下面的属性添加到我的单元测试：
[TestMethod的（）]
[HOSTTYPE（ “ASP.NET”）
[UrlToTest（ “http://mytestsite.com/Home.aspx”）
是的，你是对的，它的设计不好。 – 2009-08-18 09:02:32