我的ASP.NET App_code更改没有被提取(或缓存?)

救命!! 我在(根级别)App_Code目录下有一个.cs文件,用于检索所请求URL的正确模板(它链接到我们自己的Content Management数据库)。 最初,它工作正常 – 我可以对它进行更改,然后由Web应用程序选择它们。 然后发生了一些事情(不知道是什么),现在无论发生什么变化,它们都无法识别。 即使我删除整个App_Code目录,它也没有区别 – 我似乎仍然在使用App_Code目录中的早期(缓存??)版本。 .cs文件中的代码如下:

using System; using Custom.CMS.Facade; using Custom.CMS.BO; public class CMHttpModule : IHttpModule { code here... } 

即使我将网站复制到我们的实时服务器后,也会出现同样的问题。

我不明白的是 – 如果我向.cs代码引入故意错误,我仍然会收到编译错误,并且在成功编译时会在C:\ WINDOWS \ Microsoft.NET \ Framework下创建App_Code.xxxx.dll \ v2.0.50727 \ Temporary ASP.NET Files

那么我的Web应用程序实际上正在采用什么版本的App_Code? 如何让它拿起“正确的”?

仅供参考我使用的是C#,Visual Web Developer Express 2008和IIS 6 Web服务器

任何帮助将不胜感激。

重新打开解决方案也有效。

您是否可以右键单击该文件,转到属性并检查构建操作。 它必须设置为“编译”。

我不确定您是如何发布您的Web应用程序的,但您可以尝试以下几种方法:

  • 如前所述,检查您是否正在使用项目引用而不是从您自己的C#项目构建的DLL的文件引用。 另外,检查App_Code目录中的.cs文件是否将其Build Action设置为Compile
  • 检查所有项目是否针对相同的.NET框架:v2.0,v3.5,v4.0或v4.5。 您可以在每个项目的“ Properties的“ Application选项卡中进行检查。 请勿使用客户端配置文件变体。
  • 在源代码中,删除构建的DLL(通常是bin和obj文件夹中的DLL),然后使用Visual Studio执行完整构建。 这相当于Rebuild(读取:Clean然后Build)。 然后,发布到您的Web服务器。
  • 冒着明显的风险,确保您用于查看站点的Web浏览器在您访问站点之前已清除其缓存。

希望这可以帮助。

编辑:突然想到:这个ASP.NET Web应用程序实际上是一个网站吗? 如果是这样,那么ASP.NET编译器可能无法识别您的代码更改,因为“如果未引用代码文件,则不会编译它”。

ASP.NET 网站与ASP.NET Web 应用程序之间的主要区别在于,前者通常是在安装或更新站点后第一次收到请求时由ASP.NET在服务器上动态(自动)编译的而后者甚至在发布之前就完全编译成了DLL。 您可以在上面的链接中阅读更多相关信息。

昨天我遇到了同样的问题,我修复了它,确保网站项目上的类库引用指向您的类库项目(而不是bin文件夹中的dll)。

看起来因为该网站的目标是.net 2.0,而类库是.net 3.5,不知何故,该网站项目忽略了重建的dll并使用了网站项目bin文件夹中的那些。

@SeanW –

1)您是否尝试修改Web.Config而不是彻底删除它? Web.Config已缓存,但对其进行的任何修订都应该回收您的应用程序缓存。

2)您是否尝试过吹走整个网站,并从头开始复制? (尤其要确保删除并重新复制bin目录中的任何预编译文件。)

@Patrick –

1)您是否尝试删除临时ASP.Net文件目录中的所有内容?

2)如果您对解决方案(而不是启动项目)中的依赖项目进行了修订,您是否单独手动重建这些依赖项目?

3)您是否有权在IIS中为您的实时网站回收应用程序池?

4)您是否尝试从头开始重新修改您的实时网站或修改您的实时网站中的Web.Config?

常规应用缓存技巧 –

  • 您通常可以通过对Web.Config文件进行简单修订来刷新应用程序缓存。

  • 正如此线程中所讨论的,Global.asax更改,bin目录更改以及App_Code更改也可能会触发应用程序池的刷新。

  • 作为长期解决方案,您可能希望通过文件依赖关系或SQLCacheDependency类来管理应用程序缓存。 (虽然最后的建议可能不适用于像GoDaddy这样的共享托管网站。)

ASP.NET Web应用程序有几个陷阱。 重新加载项目是解决几个问题的一种方法……奇怪的是,确实(称我为bug)! 就个人而言,我更喜欢具有JIT编译function的ASP.Net网站(而不是应用程序) 。 FMO,它是维护prj的更快,更简单和更简单的方法。