un tipo de proxy con la cuenta de nombre ha sido definido por otro ensamblado

Tenemos 2 órdenes funcionando en nuestro sistema on-premise crm 2011.
Hemos generado clases enlazadas tempranas para ambos orgs.
Uno de nuestros complementos arroja el error "un tipo de proxy con la cuenta de nombre ha sido definida por otro ensamblado" al desactivar una cuenta.
Ese complemento solo hace referencia a uno de los dll enlazados al principio.

Cómo hago para que el sistema CRM respete el espacio de nombres de estas referencias.
He intentado los pocos artículos que aparecen en Google y ninguno funciona.un tipo de proxy con la cuenta de nombre ha sido definido por otro ensamblado

Dado que puede reproducir esto con 2 organetas, me gustaría imaginar que hay algo FUERA de la capa de código que podemos hacer sin tener que volver atrás y refactorizar un montón de código para las 2 orgs.

Gracias,
Jon

Fuente

2011-12-21 user1231231412

es el plugin registrada en la caja de arena? ¿Estás seguro de que el espacio de nombres es diferente para ambos archivos generados? – ccellar

Esto normalmente significa que hay uno o más conjuntos con el mismo nombre de método o propiedad a fijar este uso el nombre completamente calificado del conjunto .. por ejemplo en el uso del sistema. IO, por ejemplo, si tuvieras un método con el mismo nombre en tu código de Clase que entra en conflicto con System.IO .... escribirías tu arreglo como thisObject.System.IO.Path (----) = somthing por ejemplo .. Esto tiene sentido..?

Fuente

2011-12-21 19:06:44 MethodMan

thx para el comentario. Creo que este es un problema específico de CRM 2011 que realiza algún tipo de carga de reflexión y almacenamiento en caché en lugar de una referencia ambigua. – user1231231412

¿Utiliza CRM algo en el efecto de cargar un ensamblaje en particular? Perdón por mi malentendido. – MethodMan

sin preocupaciones, no creo que nadie realmente entienda lo que CRM está haciendo: D. Sí, por lo que he leído, CRM hace algún tipo de caché de tipo en todos los orgs. Lo que causaría un problema obvio ya que TODOS tienen los mismos tipos incorporados. – user1231231412

El problema está en realidad con WCF que intenta deserializar la respuesta del servidor y no poder identificar el tipo correcto. El mejor método para resolver este problema es pasar el ensamblado actual utilizando Assembly.GetExecutingAssembly() a ProxyTypesBehavior() al crear el proxy como tal.

using (serviceProxy = new OrganizationServiceProxy(config.OrganizationUri, 
       config.HomeRealmUri, 
       config.Credentials, 
       config.DeviceCredentials)) 
     { 
      // This statement is required to enable early-bound type support. 
      serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior(Assembly.GetExecutingAssembly())); 
     }

Fuente

2012-10-10 19:53:20

Si necesita hacer esto con una instancia de OrgnizationService (Microsoft.Xrm.Client.Services.OrganizationService) (como lo haría si está utilizando CrmConnection), entonces necesita crear una clase contenedora alrededor de OrganizationService para que pueda acceder al Método ToOrganizationServiceProxy y elimine el comportamiento predeterminado, luego agregue el nuevo desde arriba. – GotDibbs

Encontré que agregar Assembly.GetExecutingAssembly() resolvió el problema.

Fuente

2013-02-20 09:55:12 JFK007

añadiendo el Assembly.GetExecutingAssembly() a resolver mi problema, también es necesario añadir using System.Reflection;

gracias

Fuente

2015-09-30 16:38:04 joshuaPL

Puede ejecutar en este problema al hacer referencia a diferentes montajes que contiene de proxy-clases, es decir, un conjunto de envolver el SDK de servidor (Microsoft.Xrm.Sdk) y otro ensamblado que ajusta el SDK de cliente (Microsoft.Xrm.Sdk.Client). En tal caso, parece ser necesario indicarle a OrganizationServiceProxy qué ensamblaje se debe usar para resolver las clases de proxy.

Esto debería ayudar:

var credentials = new ClientCredentials(); 
credentials.Windows.ClientCredential = new System.Net.NetworkCredential(userName, password, domain); 

var proxy = new OrganizationServiceProxy(new Uri(discoveryUrl), null, credentials, null); 
proxy.EnableProxyTypes(typeof(CrmServiceContext).Assembly); 

var context = CrmServiceContext(proxy);

Lo importante es llamar EnableProxyTypes pasando el montaje correcto. Vi otro solution using CrmConnection, pero CrmConnection solo está disponible en el SDK del cliente, lo que significa que no puede crear una instancia de "server-OrganizationServiceProxy" de esta manera. EnableProxyTypes (ensamblaje de ensamblaje) funciona para ambos lados.

Espero que esto ayude.

Saludos, MH

Fuente

2015-10-26 08:36:47

un tipo de proxy con la cuenta de nombre ha sido definido por otro ensamblado

Respuesta

Cuestiones relacionadas