.NET 程序集引用对我来说都是循环的
更新：昨晚，我认为更改保存某些报告的文件夹的工作量太大。我的解决方法是重命名该文件夹，运行我需要完成的批处理作业，然后将文件夹名称更改回原来的名称。我觉得我可以用今天剩下的时间和下周的整个时间来处理这个问题，但仍然没有什么可展示的。我宁愿因为与老板作对而陷入地狱，也不愿向客户开具发票（这种情况每年只发生一次）。感谢所有提供帮助的人，你们愿意帮助一些匿名的人，让我感到谦卑。我不知道如何“放弃”这个问题，但仍然给你们提供支持，我会在午餐时阅读常见问题解答和任何评论。谢谢。
我正在尝试调试我的前任创建的 ac# 应用程序。他是一名程序员，我是一名系统管理员，也许这就是我出错的地方。
无论如何，我需要重新编译其中一个程序集并将其部署到我们的生产服务器。当我编译它时，我收到错误：
类型“Mcrcsip.Web.McrcsipWebExceptionBase”是在未引用的程序集中定义的。您必须添加对程序集“Mcrcsip.Web，Version=2.0.3266.28977，Culture=neutral，PublicKeyToken=c3de6c6abcdf794b”的引用。
我碰巧有该程序集的副本，当我删除对现有程序集的引用（具有不同公钥令牌的 2.0.0.0）并添加对其所要求的程序集的引用时，在编译时，出现此错误信息：
类型 'Mcrcsip.Web.McrcsipWebExceptionBase 是在一个程序集中定义的 没有引用。您必须添加一个 引用程序集“Mcrcsip.Web”， 版本=2.0.0.0，文化=中立， PublicKeyToken=8bbdde85caf008d0'。
如果我在谷歌上搜索这个错误（当然是通用的），我会得到一堆“这就是添加程序集引用的方式......”结果。
我该如何离开这个旋转木马？
解决方案的布局如下：
- Mrcsip.Amwa.Solution
http://amwa-test.internal.lan/- Mcrcsip.Amwa.Core
- Mcrcsip.Aws.Bol
- Mcrcsip.Common
- Mcrcsip.Web
- nunit.framework
- 系统
- 系统.配置
- 系统数据
- 系统.企业服务
- 系统.Web
- 系统.Web.服务
- 系统.XML
- Mcrcsip.Amwa.CrFactory
- CrystalDecisions.CrystalReports.Engine
- CrystalDecisions.Enterprise.Framework
- CrystalDecisions.Enterprise.InfoStore
- CrystalDecisions.ReportSource
- CrystalDecisions.Shared
- CrystalDecisions.Web
- Mcrcsip.Amwa.Core
- Mcrcsip.Web
- 系统
- 系统配置
- 系统数据
- 系统.绘图
- 系统.Web
- 系统.XML
- Mcrcsip.Amwa.PdfFormHandler
- itextsharp
- Mcrcsip.Amwa.Core
- Mcrcsip.Web
- 系统
- 系统.配置
- 系统数据
- 系统.Web
- 系统.Xml
- Mcrcsip.Amwa.Web
- Mcrcsip.Amwa.Core
- Mcrcsip.Amwa.CrFactory
- Mcrcsip.Amwa.PdfFormHandler
- Mcrcsip.Aws.BOL
- Mcrcsip.Common
- Mcrcsip.SharePoint
- Mcrcsip.Web
- 系统
- 系统配置
- 系统数据
- 系统.EnterpriseServices
- 系统.Web
- 系统.Web.服务
- 系统.XML
- Mcrcsip.Amwa.WebControls
- 系统
- 系统数据
- 系统.设计
- 系统.绘图
- 系统.Web
- 系统.Xml
- Mcrcsip.Amwa.Setup
Update: Last night, I decided that this is just too much work to change the folder where some reports are saved. My work-around here is to rename the folder, run the batch job I need done, and then change the folder name back to what it was originally. I feel like I could spend the rest of today and all of next week working on this and still have nothing to show. I'd rather catch hell for going against my boss than not be able to invoice our customers (which only happens once a year). Thank you to all those who have helped, I'm humbled by your willingness to help some anonymous fella in over his head. I'm not sure how to "abandon" this question but still give you guys props, I'll read the faq and any comments during lunch. Thank you.
I'm trying to debug a c# application that my predecessor created. he's a programmer, I'm a sysadmin, maybe that's where I'm going wrong.
Anyway, I need to recompile one of the assemblies and deploy it to our production server. When I compile it, I get the error:
The type 'Mcrcsip.Web.McrcsipWebExceptionBase is definined in an assembly that is not referenced. You must add a reference to assembly 'Mcrcsip.Web, Version=2.0.3266.28977, Culture=neutral, PublicKeyToken=c3de6c6abcdf794b'.
I happen to have a copy of that assembly, and when I delete the reference to the existing assembly (2.0.0.0 with a different public key token) and add a reference to the assembly it's asking for, when I compile, I get this error message:
The type
'Mcrcsip.Web.McrcsipWebExceptionBase
is definined in an assembly that is
not referenced. You must add a
reference to assembly 'Mcrcsip.Web,
Version=2.0.0.0, Culture=neutral,
PublicKeyToken=8bbdde85caf008d0'.
If I search for this error on google (genericised, of course) I get a bunch of "this is how you add an assembly reference..." results.
How do I get off this merry-go-round?
Here's how the solution's laid out:
- Mcrcsip.Amwa.Solution
http://amwa-test.internal.lan/- Mcrcsip.Amwa.Core
- Mcrcsip.Aws.Bol
- Mcrcsip.Common
- Mcrcsip.Web
- nunit.framework
- System
- System.Configuration
- System.Data
- System.Enterprise Services
- System.Web
- System.Web.Services
- System.XML
- Mcrcsip.Amwa.CrFactory
- CrystalDecisions.CrystalReports.Engine
- CrystalDecisions.Enterprise.Framework
- CrystalDecisions.Enterprise.InfoStore
- CrystalDecisions.ReportSource
- CrystalDecisions.Shared
- CrystalDecisions.Web
- Mcrcsip.Amwa.Core
- Mcrcsip.Web
- System
- System.configuration
- System.Data
- System.Drawing
- System.Web
- System.XML
- Mcrcsip.Amwa.PdfFormHandler
- itextsharp
- Mcrcsip.Amwa.Core
- Mcrcsip.Web
- System
- System.Configuration
- System.Data
- System.Web
- System.Xml
- Mcrcsip.Amwa.Web
- Mcrcsip.Amwa.Core
- Mcrcsip.Amwa.CrFactory
- Mcrcsip.Amwa.PdfFormHandler
- Mcrcsip.Aws.BOL
- Mcrcsip.Common
- Mcrcsip.SharePoint
- Mcrcsip.Web
- System
- System.configuration
- System.Data
- System.EnterpriseServices
- System.Web
- System.Web.Services
- System.XML
- Mcrcsip.Amwa.WebControls
- System
- System.Data
- System.Design
- System.Drawing
- System.Web
- System.Xml
- Mcrcsip.Amwa.Setup
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
参考不一致或：我如何学会如何停止担心并热爱ILDASM
咳咳，咳嗽，
问题
尼克，
通过重新阅读您的原始帖子，很明显您已经dll版本不一致问题。也就是说，您的解决方案中至少有一个项目依赖于 Mcrcsip.Web 版本 X，并且您的解决方案中至少有一个项目依赖于 Mcrcsip.Web 版本 Y [或更糟糕的是，依赖于依赖于 Mcrcsip.Web 版本 Y 的库]。追踪这些可能既困难又乏味。
请参阅推荐解决方案跳到最后。
如何实现
时，就会出现这种不一致
与我们直观的预期相反，当我们构建 A 时，B 不会自动更新为使用 C ver 2。A 和 B 都必须引用相同库正确构建。因此，要么 A 必须符合 C ver 1，要么 B 必须重新构建并符合 C ver 2。
现在，这种情况可能发生在任何项目配置中，这就是为什么对软件进行版本控制很重要[相信我，如果没有这个问题，这个问题会变得更糟正确的签名\版本控制]，并在发生依赖项更新时在团队内进行良好的沟通。
还值得知道的是，有两种依赖引用，硬依赖引用和软依赖引用[实际上，它们是相同的，即指向 dll 的链接，除了一种是另一种的特殊情况，从概念上讲，这有助于区分两者]。
硬引用
硬引用是项目对静态 dll 的依赖。也就是说，依赖关系是在特定时间构建的，并且永远不会更新，除非其物理文件被新文件替换。通过“添加引用”对话框以及从 .Net、COM 或浏览选项卡添加引用，可以将硬引用添加到解决方案中。硬引用通常用于添加对当前解决方案范围之外开发的软件的依赖关系[即由其他内部团队开发的框架、第三方和其他第一方产品]。硬引用也有变得过时的趋势，因为它们是由自己的开发流维护和更新的。
假设上面的场景
此外，假设 A 和 B 都在相同的解决方案
当构建 A 时，您将收到您所描述的错误。 A 期望来自 C v2 的对象，但由于 B 对 C v1 具有硬依赖关系，因此 C v1 首先加载到内存中，从而发生冲突。 A 期望 v2 并找到 v1。那是你的错误。
要解决这种情况，您必须
软引用
A 软引用是同一解决方案中一个项目对另一个项目的依赖关系。也就是说，每次重建整个解决方案时都会重建依赖关系。通过“添加引用”对话框将软引用添加到解决方案中，并从“项目”选项卡添加引用。软引用通常用于添加对当前解决方案范围内开发的软件的依赖关系，它们的主要优点是在同一解决方案中将更改传播给消费者。由于这个事实，软引用不可能是陈旧的。
[这是硬引用的特殊情况，Visual Studio 将添加一个指向目标项目的输出路径的引用，我相信如果目标项目更改其输出配置，它也会更新此路径 - 但这是一个非常方便的功能保证区别]
假设上面的场景
此外，假设 A 和B 在同一个解决方案
当构建 A 时，您将收到您所描述的错误。 A 期望来自 C v2 的对象，但由于 B 对 C v1 具有硬依赖关系，因此 C v1 首先加载到内存中，从而发生冲突。 A 期望 v2 并找到 v1。那是你的错误。
要解决此问题，
正如您所看到的，软引用更容易维护。
IL DASM [中间语言 DisASeMbler]
既然您对引用和项目维护有了更多了解，那么您究竟如何确定构建的状态呢？毕竟，任何一个项目或其依赖项都可能不一致。
最简单的方法是打开构建输出目录，然后检查解决方案生成的每个 dll 的程序集清单。
要检查程序集的清单，
ildasm窗口这是繁琐且痛苦的，但如果您遇到[非平凡] dll 不一致错误，这是找到它的唯一方法。
推荐的解决方案
如果您在此步骤中仍然遇到错误，则您知道其中一个或全部
共享您的对 Mcrcsip.Web 的依赖，并且正在引用旧版本。如果是这种情况，则为上面列出的每个硬引用
确保执行此操作上述三个硬引用中的每一个。一旦您确定了这三个子集中的哪一个子集引用了旧版本的 Mcrcsip.Web，您现在就可以找到该项目，更新其硬引用，重建它，然后最终更新您的强>硬引用，重建，瞧。鲍勃是你叔叔。
唷。
Le fin
PS 对于冗长表示歉意。这不是一个非常复杂的问题，但我相信您会同意，它涉及很多细节。我真的希望这有帮助。也感谢您的合作:)
PPS 顺便说一句，我从您的评论中推断原始开发人员在各处都使用了硬引用[即即使在同一解决方案中]。也许他有他的理由，但在我看来，那是屁股。
Reference inconsistencies or: how i learned how to stop worrying and love ILDASM
ahem, cough cough,
Problem
Nick,
From re-reading your original post, it is clear that you have a dll version-inconsistency issue. That is, at least one project in your solution depends on Mcrcsip.Web version X, and at least one project in your solution depends on Mcrcsip.Web version Y [or worse still, depends on a library that depends on Mcrcsip.Web version Y]. These can be difficult and tedious to track down.
See Recommended Solution to skip to the end.
How
This sort of inconsistency arises when
contrary to what we intuitively expect, B will not auto-magically update to use C ver 2 when we build A. Both A and B must reference the same library to build properly. So either A must conform to C ver 1, or B must be rebuilt and conform to C ver 2.
Now, this can happen in any project configuration, which is why it is important to version your software [believe me this problem gets worse without proper signing\versioning], and communicate well within your team whenever a dependency update occurs.
It is also worth knowing there are two kinds of dependency references, hard and soft [in actual fact, they are the same, that is links to dlls, except one is a special case of the other, and conceptually it helps to distinguish the two].
Hard References
A hard reference is a dependency of a project to a static dll. That is, the dependency was built at a specific time and will never update unless its physical file is replaced with a new one. Hard references are added to a solution via Add References dialog, and adding a reference from the .Net, COM, or Browse tabs. Hard references are typically used to add dependencies to software developed outside the scope of the current solution [ie framework, third party, and other first party products developed by other internal teams]. Hard references also have a tendency to become stale, because they are maintained and updated by their own development stream.
Assume scenario above
Further, assume A and B are within the same solution
When A is built, you will receive the error you described. A expects an object from C v2, but because B has a hard dependency on C v1, C v1 is loaded into memory first, and a collision occurs. A expects v2 and finds v1. That is your error.
To resolve this situation, you must
Soft References
A soft reference is a dependency of a project to another project within the same solution. That is, the dependency is rebuilt every time the entire solution is rebuilt. Soft references are added to a solution via Add References dialog, and adding a reference from the Projects tab. Soft references are typically used to add dependencies to software developed inside the scope of the current solution, they have the primary advantage of propagating changes as they are made to consumers within the same solution. By virtue of this fact, soft references cannot be stale.
[this is a special case of a hard reference, Visual Studio will add a reference that points to the output path of the target project, i believe it also updates this path if the target project changes its output configuration - but a very handy feature that warrants distinction]
Assume scenario above
Further, assume A and B are within the same solution
When A is built, you will receive the error you described. A expects an object from C v2, but because B has a hard dependency on C v1, C v1 is loaded into memory first, and a collision occurs. A expects v2 and finds v1. That is your error.
To resolve,
As you can see, soft references are easier to maintain.
IL DASM [Intermediate Language DisASeMbler]
Now that you know a bit more about references, and project maintenance, how exactly do you ascertain the state of your build? After all, any one of your projects or their dependencies may be inconsistent.
The easy way is to open your build output directory, and inspect the assembly manifest of each and every single dll that your solution produced.
To inspect an assembly's manifest,
ildasm.exeildasmwindowThis is tedious and painful, but if you encounter a [non-trivial] dll inconsistency error, this is the only way to find it.
Recommended Solution
If you still encounter errors at this step, then you know that one or all of
shares your dependency on Mcrcsip.Web, and is referencing the old version. If this is the case, then for each hard reference listed above
ildasmMake sure you do this for each and every one of the three hard references above. once you identify which subset of those three are referencing the old version of Mcrcsip.Web, you may now find that project, update its hard reference, rebuild it, and then finally update your hard reference, rebuild, and voila. Bob's your uncle.
Phew.
Le fin
PS apologies for verbosity. this isn't a terribly complex problem, but as i am sure you would agree, it involves a lot of detail. i really hope this helps. thanks for your co-operation too :)
PPS btw, i am inferring from your comments that original developer used hard references everywhere [ie even within same solution]. perhaps he had his reasons, but imo, that is ass.
如果右键单击引用，转到属性，“特定版本”设置为什么？确保它设置为“True”并且列出的版本确实是 2.0.x。
在属性页面中，仔细检查路径。您可能在 GAC 的其他地方注册了优先的不同版本。在命令行中使用“gacutil -l”来获取该程序集的所有注册版本的列表。如果您看到具有不同密钥的重复项，请使用 gacutil 删除您不想要的密钥。
If you right-click the reference, go to properties, what is "Specific Version" set to? Make sure that it is set to 'True' and the version listed is indeed 2.0.x.
In the properties page, double-check the path. You might have a different version registered elsewhere in your GAC that is getting precedence. Use "gacutil -l " in the command line to get a list of all registered versions of that assembly. If you see duplicates with different keys, use gacutil to nuke the one you don't want.
观看“批量构建”选项下的其他构建。这将让您优先考虑首先构建哪个程序集，然后依赖项将根据需要以正确的顺序获取其 DLL。
Watch the build other under the Batch Build options. This will let you prioritize what assembly to build first, then dependencies shall get their DLL as required in the proper order.