将 MVC 1 应用程序部署到远程服务器时 Global.asax 解析器错误

发布于 2024-08-31 05:21:25 字数 1299 浏览 3 评论 0原文

因此,我们在将 ASP.NET MVC 应用程序部署到客户端站点时遇到了一些问题。基本上,当我们尝试从本地主机测试应用程序时,我们会收到可怕的 Global.asax 解析器错误,表明它无法全局加载应用程序。

研究表明,我们看到的这种异常基本上有 4 个可能的原因:

  1. 解决方案尚未构建。显然情况并非如此,因为我们可以在这里部署它,并且它在我们部署到的任何机器上都运行良好,而且我们必须构建并发布该死的东西才能部署它。

  2. Global.asax 命名空间继承与应用程序全局代码文件不匹配。我们再次仔细检查了这一点,因为它在这里运行得很好,所以这不可能是问题。

  3. 各种不伦不类的 IIS/VS.NET 恶作剧。基本上,IIS 或 VS.NET 中出现一些问题,Web 服务器将无法正常运行此应用程序。我们已经完成了清理和重建,删除了虚拟目录并重新创建,并执行了我们在网上其他地方找到的所有 IIS 修改。 IIS 反弹、服务器重新启动、虚拟目录/应用程序重新创建等的各种组合。

  4. 代码级别权限问题。我们已经验证了框架目录中机器/Web 配置的完全信任,我们已经在 IIS 中将 .NET 信任设置为完全,我们已经授予每个人对目录的完全控制权,只是为了用安全锤击中它,等等.

相关细节 Windows Server 2008 x64 IIS 7,32位兼容应用程序池(应用程序是在为任何CPU编译的32位操作系统上编写的) 应用程序池标识设置为 NetworkService 微软 ASP.NET MVC 1.0 XCopy 部署

我们部署了另一个只读应用程序,效果很好。这个应用程序的显着区别是使用 NHibernate 和 Log4Net,它们需要完全信任。 此外,Web 项目的实际项目名称与默认命名空间不同,但 Global.asax 和 Global.asax.cs 文件中的 Inherits 命名空间匹配,因此这不应该是问题。

有人有什么好主意吗?我们正式只剩下昏暗的了。

编辑 例外是 无法加载类型

没有代码片段,因为应用程序根本不会加载。安装后第一次请求时它立即失败,没有时间延迟。

所有这些人都是一样的这里遇到了麻烦

So we're having some issues deploying an ASP.NET MVC app to a client site. Basically when we try to test the app from localhost, we get the dreaded Global.asax parser error indicating it could not load the application global.

Research indicates there are basically 4 possible reasons for this exception we're seeing:

  1. The solution hasn't been built. This clearly isn't the case since we can deploy it here and it runs fine on any machine we deploy to AND we had to build and publish the darn thing to deploy it anyway.

  2. The Global.asax namespace inheritance does not match the application global code file. Again we double checked this and since it runs just fine here that can't be the issue.

  3. Miscellaneous non-descript IIS/VS.NET mischief. Basically something get's wonky in IIS or VS.NET and the web server won't behave correctly for this application. We've done cleans and rebuilds, we've deleted virtual dir and recreated, and performed all of the IIS munging that we've found elsewhere online. Various combinations of IIS bounces, server reboots, virtual dir/application recreation, etc.

  4. Code level permissions issue. We've verified full trust in machine/web config in the framework directory, we've set .NET trust to full in IIS, we've granted Everyone full control on the directories just to hit it with the security hammer, etc. etc.

The pertinent detials:
Windows Server 2008 x64
IIS 7, 32 bit compatible app pool (app was written on 32 bit OS compiled for any cpu)
App pool identity set to NetworkService
Microsoft ASP.NET MVC 1.0
XCopy deployment

We deployed another read-only app just fine. The significant difference in this app is the use of NHibernate and Log4Net which require full trust.
Additionally, the actual project name of the web project differs from the default namespace however the Inherits namespace in Global.asax and the Global.asax.cs files match so this shouldn't be an issue.

Anybody have any bright ideas? We're officially down to just the dim ones.

EDIT
Exception is Could not load type <MyDefaultNamespace>.<Global.asax.cs class name>

There is no code snippet as the app won't load at all. It fails immediately with no time lag on first request after install.

It's the same thing all these folks over here are having trouble with

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

抠脚大汉 2024-09-07 05:21:26

例外是“无法加载类型

没有代码片段,因为应用程序根本不会加载。安装后第一次请求时它立即失败,没有时间延迟。

所有这些人都是一样的这里遇到了麻烦

Exception is "Could not load type <MyDefaultNamespace>.<Global.asax.cs class name>"

There is no code snippet as the app won't load at all. It fails immediately with no time lag on first request after install.

It's the same thing all these folks over here are having trouble with

⒈起吃苦の倖褔 2024-09-07 05:21:25

如果您更改了解决方案平台,请尝试将其改回任何 CPU

我将我的设置为 x86(我创建的设置是为了允许在 x64 计算机上调试期间更改代码)。当我将其改回任何 CPU 时,您描述的问题就消失了。

If you have changed the solution platform, try changing it back to Any CPU.

I had mine set to x86 (one I had created to allow code changes during debugging on x64 computer). When I changed it back to Any CPU the the problem you described went away.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文