名称为 account 的代理类型已由另一个程序集定义
- 我们有 2 个组织在我们的本地 crm 2011 系统中运行。
- 我们已经为两个组织生成了早期绑定类。
- 我们的一个插件在停用帐户时抛出“名称为帐户的代理类型已由另一个程序集定义”错误。
- 该插件仅引用早期绑定的 dll 之一。
如何让 CRM 系统尊重这些引用的命名空间。
我已经尝试了谷歌显示的一些项目,但没有一个起作用。
由于您可以使用 2 个普通组织来重现此内容,我想在代码层之外我们可以做一些事情,而无需返回并为这 2 个组织重构一堆代码。
谢谢,
乔恩
- We have 2 orgs running in our on-premise crm 2011 system.
- We have generated early bound classes for both orgs.
- One of our plugins is throwing the "a proxy type with the name account has been defined by another assembly" error when deactivating an account.
- That plugin only references one of the early bound dll's.
How do I get the CRM system to respect the namespace of these references.
I've tried the few items that show up from Google and none are working.
Since you can reproduce this with 2 vanilla orgs I would imaging there is something OUTSIDE the code layer we can do without having to go back and refactor a bunch of code for the 2 orgs.
Thanks,
Jon
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
问题实际上是 WCF 尝试反序列化服务器响应但无法识别正确的类型。解决此问题的最佳方法是在创建代理时使用 Assembly.GetExecutingAssembly() 将当前程序集传递给 ProxyTypesBehavior(),如下所示。
The problem is actually with WCF attempting to deserialize the server response and not being able to identify the correct type. The best method to sort this issue is to pass in the current assembly using Assembly.GetExecutingAssembly() to the ProxyTypesBehavior() while creating the proxy like so.
当引用包含代理类的不同程序集时,您可能会遇到此问题,即一个程序集包装服务器 SDK (Microsoft.Xrm.Sdk),另一个程序集包装客户端 SDK (Microsoft.Xrm.Sdk.Client)。
在这种情况下,似乎需要告诉 OrganizationServiceProxy 应该使用哪个程序集来解析代理类。
这应该有所帮助:
重要的是通过传递正确的程序集来调用 EnableProxyTypes。我看到另一个 使用 CrmConnection 的解决方案,但 CrmConnection 仅在客户端 SDK 中可用,这意味着您无法实例化“服务器-OrganizationServiceProxy”这样。 EnableProxyTypes(Assembly assembly) 适用于双方。
希望这有帮助。
问候,
MH
You may run into this issue when referencing different assemblies containing proxy-classes, i.e. one assembly wrapping the server SDK (Microsoft.Xrm.Sdk) and another assembly wrapping the client SDK (Microsoft.Xrm.Sdk.Client).
In such a scenario it seems to be required to tell the OrganizationServiceProxy which assembly should be used to resolve the proxy classes.
This should help:
The important thing is to call EnableProxyTypes by passing the correct assembly. I saw another solution using CrmConnection but CrmConnection is only available in the client SDK, which means that you can't instantiate a "server-OrganizationServiceProxy" this way. EnableProxyTypes(Assembly assembly) works for both sides.
Hope this helps.
Regards,
MH
自从这个问题被提出以来可能已经有很多年了。然而,我最近遇到了这个问题,并且非常担心要更改数千行代码。然而,我很幸运地发现以下简单的更改可以让自己摆脱困境:
假设您处理两个上下文对象:
和一个 OrganizationServiceProxy 对象:service
if in a single方法中,您使用相同的服务对象但使用上述任一上下文对象进行多个 CRUD 操作,则很可能会引发此错误。但是,通过执行以下操作,您可以防止这种情况发生。
每次您想要使用 context1 时,请在上下文对象之前添加服务对象,如下所示:
此外,每次您想要使用 context2 时,您都遵循相同的结构:
It maybe years since this question has been raised. However, I faced this problem recently and have been extremely worried about thousands of lines of code to be changed. However, I was lucky to find the following simple change to get myself out of hell:
Suppose there are two context objects you deal with:
and a single OrganizationServiceProxy object: service
if in a single method, you make multiple CRUD operations using the same service object but with either of context objects as exemplified above, it is highly probable that this error be raised. However, by doing the following, you can prevent it to happen.
Every time you want to work with context1, you precede the context object with the service object as following:
Also, every time you want to work with context2, you follow the same structure:
这通常意味着有一个或多个程序集具有相同的方法名称或属性来解决此问题,请使用程序集的完全限定名称。例如,在使用 System.IO 中,如果您有一个以相同方式命名的方法你的类代码与 System.IO 冲突......你会像这样编写你的修复
thisObject.System.IO.Path( ---- ) = 例如某物.. 这有意义吗..?
this normally means that there is one or more assemblies with the same method name or property to fix this use the fully qualified name of the assembly.. for example in the using System.IO for example if you had a method named the same way in your Class code that conflicts with System.IO.... you would write your fix like
thisObject.System.IO.Path( ---- ) = somthing for example.. does this make sense..?
我发现添加 Assembly.GetExecutingAssembly() 解决了问题。
I found that adding the Assembly.GetExecutingAssembly() solved the problem.
添加 Assembly.GetExecutingAssembly() 解决了我的问题,您还需要添加
using System.Reflection;
谢谢
adding the Assembly.GetExecutingAssembly() solve my problem, you also need to add
using System.Reflection;
thanks
使用 OpenAPI 和新的 Dataverse 客户端 (ServiceClient) 时,.Net6 上也会出现问题。
我发现的唯一修复方法是使用程序集引用克隆设置的 ServiceClient:
Issue also occurs on .Net6 when using OpenAPI and the new Dataverse Client (ServiceClient).
Only fix I've found is cloning the setted up ServiceClient with the Assembly reference: