ASP.NET 网站编译 - Intellisense 在外部程序集中看到新属性，但编译时验证失败
我有一个网站“项目”。它具有对我们不时更新的外部 DLL 的程序集引用（某种“框架”）。 Visual Studio 2008 愉快地创建了“刷新”文件，用于在编译时更新引用。
我在外部程序集中添加了一个枚举并重新编译它。回到网站项目，我更新了引用（通过右键单击“Bin”文件夹下列出的外部 DLL 并选择“更新引用”，然后进入网站的属性页和引用页面，突出显示我的外部程序集并单击“更新”按钮。
我对网站的 App_Code 文件夹中的一个类进行了一些更改，该类使用外部程序集的新枚举值，并且 IDE 会执行此操作。根本不抱怨我使用它 - 直到我尝试构建解决方案
时，我收到错误 BC30456，这是“'{0}' 不是 {1} 的成员”错误。错误保留在“错误列表”视图和“输出”窗口中，直到我再次更新对外部程序集的引用，之后错误立即消失，
如果我从项目中完全删除引用，VS 会正确地开始抱怨 。关于缺少枚举类型并发出警告找不到我尝试导入的名称空间。当我重新添加程序集引用时，几秒钟后所有错误和警告都会消失。第一次尝试重建解决方案和/或网站时，我再次收到错误。
我试图通过执行以下任务来确认我没有疯狂：
- 清理网站的临时 ASP.NET 文件文件夹，包括 32 位和 64 位版本的框架
- 直接从外部位置手动复制程序集进入 Bin 文件夹
- 关闭并重新打开 Visual Studio
- 重新启动计算机
我现在刚刚注意到的一件事是外部 DLL 上次构建于 11/14/2011。当该版本的 DLL 位于 Bin 文件夹中时，Intellisense 是准确的。一旦我尝试构建，DLL 和 PDB 就会恢复为 2011 年 11 月 7 日构建。我不知道这是从哪里来的。该机器上该 DLL 的 DEBUG 和 RELEASE 版本均适用于 11/14。 DLL 没有签入我们的源代码控制系统，只有 .refresh 文件签入，因此无法从源代码控制服务器更新它们。
我真的真的很困惑，正在寻找你可能有的任何想法。
I have a website "project". It has assembly references to external DLLs that we update from time to time (a "framework" of sorts). Visual Studio 2008 happily creates the "refresh" files that it uses to update references at compile time.
I made an addition to an enum in the external assembly and recompiled it. Back in the website project, I updated the reference (both by right-clicking the external DLL that's listed under the "Bin" folder and choosing "Update Reference" and by going into the Property Pages for the website and on the References page, highlighting my external assembly and clicking the "Update" button.
There's a class in the website's App_Code folder that I made some changes to that use the new enum value from the external assembly. Intellisense picks up the new addition and the IDE does not complain about me using it at all -- until I try to build the solution.
Upon building the solution, I get an error BC30456, which is a "'{0}' is not a member of {1}" error. The error stays in the "Error List" view and on the "Output" window until I once again Update the reference to the external assembly, after which the error goes away immediately.
If I remove the reference from the project completely, VS correctly starts complaining about missing the enum type and warns that the namespace I'm trying to import cannot be found. When I re-add the assembly reference, after a few seconds all of the errors and warnings go away. Upon the first attempt at rebuilding the solution and/or the website, I get the error again.
I've tried to confirm I'm not crazy by doing these tasks:
- Cleaning out the Temporary ASP.NET files folder for the website, both 32-bit and 64-bit versions of the Framework
- Manually copying the assembly from the external location straight into the Bin folder
- Closing and reopening Visual Studio
- Restarting the computer
The ONE thing that I just noticed now is that the external DLL was last built on 11/14/2011. When that version of the DLL is in the Bin folder, Intellisense is accurate. As soon as I try a build, the DLL and PDB revert to an 11/7/2011 build. I do not know where this is coming from. Both the DEBUG and RELEASE builds of that DLL on this machine are for 11/14. The DLLs are not checked in to our source control system, only the .refresh files are, so it can't be updating them from the source control server.
I'm really, truly, stumped, and looking for any ideas you may have.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当然，我在问问题 5 分钟后就想到了......
该网站项目有另一个外部程序集参考 (B)，它取决于我遇到问题的那个 (A)。构建时，当它更新引用 B 时，它会使用构建 B 的 bin 文件夹中的 DLL（恰好是 11/7 构建）覆盖 .refresh 文件中位置的引用 A 的 DLL。
更新参考 A 将正确的 DLL 复制到 Bin 文件夹中。更新引用 B 在编译时覆盖了它。
And of course I figure it 5 minutes after asking the question...
The website project has another external assembly reference (B) which depends on the one I was having trouble with (A). Upon build, while it was updating reference B, it was overriding reference A's DLL from the location in the .refresh file with the DLL from the bin folder of where B was built, which happened to be the 11/7 build.
Updating reference A copied the correct DLL into the Bin folder. Updating reference B overrode it at compile time.