Bin 部署的 MVC 应用程序需要不同的清单
这正在认真地开始烘烤我的面条。我刚刚构建并部署（通过 FTP）一个普通的 ASP.Net MVC 应用程序（版本 1.0.0.0），但在部署后遇到了以下问题：
无法加载文件或程序集 'System.Web.Mvc，版本=1.0.0.0， 文化=中立， PublicKeyToken=31bf3856ad364e35' 或 它的依赖项之一。该模块 预计将包含一个集会 明显。
堆栈跟踪可见于 http://demos.officeacuity.com。
我已遵循Phil Haack 建议的所有步骤 在部署应用程序时，我怀疑这不是我复制的实际 DLL 的问题。 MVC 的程序集版本在 Web.Config 中正确指定，路由和抽象版本也是如此，因此我们将不胜感激来自社区的任何建议或线索。
This is seriously starting to bake my noodle. I've just built and deployed (via FTP) a vanilla ASP.Net MVC application (version 1.0.0.0), but have struck the following problem after deployment:
Could not load file or assembly
'System.Web.Mvc, Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The module
was expected to contain an assembly
manifest.
Stack trace visible at http://demos.officeacuity.com.
I've followed all the steps suggested by Phil Haack in deploying the application, and suspect this isn't an issue with the actual DLLs I've copied up anyway. The assembly versions for MVC are correctly specified in Web.Config, as are the Routing and Abstractions ones, so any suggestions or clues from the community would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
服务器可能在 GAC 中有一个 System.Web.Mvc dll 版本。您可以使用配置文件指向您正在使用的版本：
http:// /msdn.microsoft.com/en-us/library/7wd6ex19.aspx
http://msdn.microsoft.com/en-我们/库/yx7xezcf%28VS.71%29.aspx
It could be that the server has a version of the System.Web.Mvc dll in the GAC. You can use your config file to point to the version you are using:
http://msdn.microsoft.com/en-us/library/7wd6ex19.aspx
http://msdn.microsoft.com/en-us/library/yx7xezcf%28VS.71%29.aspx
事实证明，有两个并发问题在起作用。主要是Web主机的服务器上没有安装MVC。虽然我认为复制 MVC（和相关）DLL 可以消除这个问题，但显然情况并非如此。
另一个问题是，我之前一直在使用 MVC 2.0 预览版，尽管 MVC 1.1 是实际使用的程序集，但 Web.Config 仍然引用该版本。
It turns out there were two concurrent issues at play. The main one was that the web host did not have MVC installed on the server. While I thought that copying up the MVC (and related) DLLs would have removed this problem, apparently this was not the case.
The other issue was that I'd been playing with the MVC 2.0 Preview release previously and the Web.Config still had references to that version even though MVC 1.1 was the actual assembly being used.