2012-04-13 15 views
4

Ich verfüge über eine benutzerdefinierte Workflowaktivitätsassembly, auf die von zwei Workflows verwiesen wird. Die Assembly befindet sich derzeit in Version 1.0.builddate.revision.Fehler beim Aktualisieren einer benutzerdefinierten Workflowaktivitätsassembly in CRM 2011

Ich habe ein Update für die Baugruppe neu kompiliert. Es ist jetzt bei 1.1.builddate.revision.

Basierend auf Informationen, die ich gefunden here Ich glaube, dass, da ich die Minor-Nummer in der Assembly-Version ändern, würde ein Upgrade (keine Aktualisierung) der benutzerdefinierten Workflow-Aktivität durchführen müssen.

Mein Verständnis eines Upgrades ist im Wesentlichen, dass ich nur eine neue Assembly registrieren und dann die Prozessworkflows auf die neue Revision der benutzerdefinierten Aktivitäten verweisen sollte.

Wenn ich jedoch versuche, die Assembly (programmgesteuert) zu registrieren, erhalte ich eine FaultException, die nichts mehr angibt als "Kann keinen doppelten Schlüssel einfügen".

System.ServiceModel.FaultException<Microsoft.Xrm.Sdk.OrganizationServiceFault> was caught 
    Message=Cannot insert duplicate key. 
    Source=mscorlib 
    Action=http://schemas.microsoft.com/xrm/2011/Contracts/Services/IOrganizationService/CreateOrganizationServiceFaultFault 
    StackTrace: 
    Server stack trace: 
     at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) 
     at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) 
     at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) 
     at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) 
    Exception rethrown at [0]: 
     at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) 
     at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) 
     at Microsoft.Xrm.Sdk.IOrganizationService.Create(Entity entity) 
     at Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy.CreateCore(Entity entity) 
     at Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy.Create(Entity entity) 
     at PluginRegistrationTool.XrmService.Create(Entity entity) in C:\Workspaces\xxxxxx\Lib\PluginRegistrationTool\PluginRegistrationTool\XrmService.cs:line 390 
    InnerException: 

Ich kann nur raten, auf welche Taste sich dieser Fehler bezieht. Zuerst dachte ich, dass ich vielleicht versuchte, eine alte Kopie der Assembly hochzuladen (möglicherweise eine, die noch v1.0.xx war), aber ich kann über Intellisense überprüfen, dass ich tatsächlich eine neuere Version der Assembly hochlade, als sie existiert in der Organisation, in der ich versuche, mich anzumelden. Alles an der Assembly für benutzerdefinierte Aktivitäten ist bis auf die AssemblyVersion-Nummer identisch.

Was bekomme ich nicht über diesen Prozess? Ich muss nicht wissen, wie ich den Workflow aktualisieren muss, um auf die neue Assembly zu verweisen ... Ich möchte nur wissen, wie eine aktualisierte benutzerdefinierte Workflowaktivitätsassembly erfolgreich in CRM hochgeladen wird.

Der Code, der versucht, die benutzerdefinierte Workflowaktivitätsassembly zu aktualisieren, ist eine geringfügig geänderte Version von this. Das PluginRegistrationTool auf dieser Codeplex-Site ist eine modifizierte Version des PluginRegistrationTool, das mit dem CRM SDK geliefert wird. Diese Version verwandelt das PluginRegistrationTool in ein Befehlszeilenprogramm, das ich in unserem Build-Prozess verwende.

Ich habe die Funktion Registrieren in this Datei geändert, um die Update vs Upgrade-Szenarien zu behandeln, durch Vergleichen der Major/Minor-Teil der AssemblyVersion Nummer der Assembly in CRM mit der Versionsnummer der Assembly, die ich hochladen möchte . Ich kann sehen, dass es ein Upgrade versucht (eine neue Baugruppe zu schaffen), aber dann bekomme ich die Ausnahme, die ich früher auf dem

erwähnt

organizationServiceProxy.Create(entity);

oder Linie 390 des Code in this Datei.

Eine wichtige Sache zu beachten ist, dass ich das Upgrade mithilfe des GUI PluginRegistrationTool aus dem SDK durchführen kann, nur nicht mit dieser Befehlszeilenversion des Tools. Außerdem wird dieselbe Fehlermeldung angezeigt, wenn ich versuche, eine verwaltete Lösung mit einer "aktualisierten" Version der benutzerdefinierten Workflowaktivitätsgruppe auf eine verwaltete Lösung mit einer älteren Version der Assembly zu importieren.

Vielen Dank im Voraus für Ihre Hilfe!

+0

Könnten Sie bitte den Code zeigen, mit dem Sie die neue Version und die vollständige FaultException registrieren? – ccellar

+0

Ich habe meine Frage aktualisiert, um die Ausnahmeinformationen zu enthalten. – Paul

+1

Ich habe meine Frage aktualisiert, um Links zu dem fehlerhaften Code hinzuzufügen. – Paul

Antwort

2

Ich erstellte die neue Assembly, indem ich die Assemblyid der vorhandenen Assemblys übergeben.Das verursachte die doppelte Schlüsselausnahme, wenn ich proxy.Create() anrief. Nachdem ich der Eigenschaft "assemblyid" der Assembly-Entität eine neue GUID zugewiesen hatte, funktionierte der Funktionsaufruf proxy.Create() einwandfrei.

Danke für die Hilfe dazu!

1

Ich habe gesehen, dass dieser Fehler auftaucht, wenn ich vergesse, die Baugruppe mit einem Schlüssel zu unterschreiben. Wechseln Sie zu den Projekteigenschaften und stellen Sie sicher, dass sie signiert sind. Ist dies nicht der Fall, heben Sie die Registrierung der Assembly auf und registrieren Sie dann die signierte Version, und Updates sollten von dort aus funktionieren.

+1

Hallo Josh. Vielen Dank für Ihre Antwort. Die Assembly wird mithilfe von ILMerge generiert, da wir auf benutzerdefinierte Geschäftslogik-Assemblys verweisen. Ich übergebe ILMErge eine Schlüsseldatei als Befehlszeilenparameter im Post-Build des Projekts. Ich gehe davon aus, dass die Versammlung jedes Mal unterschrieben wird, aber ich werde das überprüfen. Auch Assemblys mit verschiedenen Major/Minor-Nummern können nicht aktualisiert werden. – Paul

+1

Ich habe gerade Sn-T sowohl auf der alten als auch auf der neuen Assembly ausgeführt. Beide geben das gleiche öffentliche Schlüsseltoken zurück. – Paul

Verwandte Themen