2012-04-05 9 views
10

Sto cercando di capire un modo per aggiornare assiemi utilizzati dal nostro runtime worklow (attività personalizzate) pur essendo in grado di caricare (deserializzare) vecchi casi. La mia situazione è simile a questo:Caricamento precedenti flussi di lavoro della versione con la nuova versione di assemblaggio

  1. hanno un flusso di lavoro creato e insistette con CustomActivities v.1.0.0.0
  2. distribuire una nuova versione del prodotto ha strega CustomActivities v.2.0.0.0
  3. cercare di caricare i flussi di lavoro precedenti nel nuovo runtime

La differenza tra v.1 e v.2 è che nell'assembly sono presenti alcune classi aggiuntive. La struttura per i tipi esistenti non è cambiata, quindi supponevo che la deserializzazione binaria continuasse a funzionare. Noi stiamo reindirizzando tutti i tipi di v.1 a v.2 utilizzando AssemblyResolve evento

if (args.Name.Contains("CustomActivities")) 
{ 
    Type someTypeFromCustomActivities = typeof(WorkflowType); 
    return someTypeFromCustomActivities.Assembly; 
} 

Eppure ad un certo punto durante il processo di deserializzazione stiamo ottenendo la seguente eccezione:

SerializationException: L'oggetto con L'ID 153 implementa l'interfaccia IObjectReference per la quale non è possibile risolvere tutte le dipendenze. La causa probabile sono due istanze di IObjectReference che hanno una reciproca dipendenza l'una dall'altra.

cosa potrebbe causare questo comportamento e come possiamo lavorare intorno ad esso? Anche se qualcuno ha una strategia per l'aggiornamento di flussi di lavoro che non comporta lato correre da assemblee laterali (vecchie e nuove versioni dello stesso dominio applicazione) sarebbero stati accolti.

+0

Questo blog dice: > Verificare se è stato modificato il flusso di lavoro (creato qualche nuovo stato, per esempio), in tal caso verificare se il database di persistenza ha alcun persistito flusso di lavoro in esso. se ha il tuo problema potrebbe essere lì perché il flusso di lavoro non può essere serializzato di nuovo. > @AZ Potrebbe essere il tuo caso? http://brazeta.wordpress.com/2012/01/12/vs-2010-test-assert-inconclusive-exception/ – sethcall

+1

la struttura di classe/flusso di lavoro non è cambiato un po '. Inoltre non posso semplicemente cancellare i dati persistenti perché ciò significherebbe perdo workflow di produzione attivi –

risposta

2

L'evento assemblaggio volontà non fa nulla per cambiare le serializzati riferimenti tipi di montaggio. Hai provato un reindirizzamento del bind di assemblaggio a livello di macchina da v1 a v2.

Aggiornamento: Ho trovato questo link che parla di utilizzare un reindirizzamento vincolante per inoltrare i vecchi flussi di lavoro alle nuove versioni utilizzano un attributo AppliesTo.

http://msdn.microsoft.com/en-us/library/aa349375.aspx

+0

la movimentazione di assemblaggio determinazione ha esattamente lo stesso effetto del reindirizzamento config. In teoria, i vecchi dati dovrebbero corrispondere ai nuovi tipi in quanto nulla è cambiato nella loro struttura, ma il runtime del flusso di lavoro continua a mancare con l'eccezione di cui sopra. Sto cercando di ottenere un consiglio da persone che hanno riscontrato questo problema prima e da come hanno escogitato una soluzione, se ce ne sono state. –

+0

- 1 per non una risposta. questo avrebbe potuto essere un bel commento se –

+0

ero in aeroporto, mentre stavo scrivendo questo sul mio telefono, quindi mi scuso per la brevità e la mancanza di chiarezza e di avere la risposta nel posto sbagliato. –