2012-04-05 16 views
10

estoy tratando de encontrar una forma de actualizar montajes utilizados por nuestro tiempo de ejecución worklow (actividades personalizadas) sin dejar de ser capaz de cargar ( deserializar instancias antiguas). Mi situación es la siguiente:Carga de la versión anterior como flujos de trabajo con nuevo montaje de la versión

  1. tienen una instancia de flujo de trabajo creado y persistió con CustomActivities v.1.0.0.0
  2. desplegar una nueva versión de la bruja producto tiene CustomActivities v.2.0.0.0
  3. tratar de cargar flujos de trabajo previos en el nuevo motor de ejecución

La diferencia entre v.1 y v.2 es que tenemos algunas clases adicionales en el ensamblaje. La estructura para los tipos existentes no ha cambiado, así que supongo que la deserialización binaria aún funcionará. Nos vamos a redirigir todos los tipos de la versión 1 a la versión 2 usando AssemblyResolve caso

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

Sin embargo, en algún momento durante el proceso de deserialización estamos recibiendo la siguiente excepción:

SerializationException: El objeto con ID 153 implementa la interfaz IObjectReference para la cual no se pueden resolver todas las dependencias. La causa probable es dos instancias de IObjectReference que tienen una dependencia mutua entre sí.

¿Qué podría causar este comportamiento y cómo podemos evitarlo? Además, si alguien tiene una estrategia para actualizar flujos de trabajo que no implique ejecutar ensamblajes paralelos (versiones antiguas y nuevas en el mismo dominio de aplicación), serían bienvenidos.

+0

Este blog dice: > Comprobar si ha cambiado su flujo de trabajo (creado un nuevo estado, por ejemplo), si a fin de comprobar si su base de datos de persistencia tiene cualquier flujo de trabajo persistieron en él. si tiene su problema podría estar allí porque el flujo de trabajo no se puede serializar de nuevo. > @AZ ¿Podría ser este tu caso? http://brazeta.wordpress.com/2012/01/12/vs-2010-test-assert-inconclusive-exception/ – sethcall

+1

La estructura clase/flujo de trabajo no ha cambiado un poco. Además, no puedo simplemente eliminar los datos persistentes porque eso significaría que pierdo los flujos de trabajo de producción activos –

Respuesta

2

El evento assembly resolve no hace nada para cambiar las referencias del conjunto de tipos serializados. ¿Has probado una redirección de encuadernación de ensamblaje a nivel de máquina desde v1 a v2.

Actualización: Encontré este enlace que habla sobre el uso de una redirección de enlace para reenviar flujos de trabajo antiguos a nuevas versiones con un atributo de applyTo.

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

+0

el manejo de resolución del conjunto tiene exactamente el mismo efecto que la redirección de configuración. En teoría, los datos antiguos deberían coincidir con los nuevos tipos, ya que nada ha cambiado en su estructura y, sin embargo, el tiempo de ejecución del flujo de trabajo falla con la excepción anterior. Estoy tratando de obtener algunos consejos de personas que se han encontrado con este problema antes y cómo se ideó una solución, en su caso. –

+0

- 1 por no respuesta. esto podría haber sido un buen comentario, aunque –

+0

Estaba en el aeropuerto mientras escribía esto en mi teléfono, así que me disculpo por la brevedad y la falta de claridad y por tener la respuesta en el lugar equivocado. –

Cuestiones relacionadas