Altri 4 piccoli Tip

Argomenti di tipo Generico

Non è possibile impostare un’activity XAML in modo che accetti/restituisca Argument di tipo generico. Bisogna ricorrere al tipo object. D’altronde ciò evidente anche dal fatto che utilizzando WorkflowInvoker per passare i parametri si utilizza un IDictionary<String, Object>

 

Service Proxy

L’aggiunta di un Service Reference si comporta in maniera diversa rispetto a quanto avviene in altre tipologie di progetto. VS, infatti, non crea un ServiceClient ma n. Activity per quanti sono i servizi esposti.

 

Errori

Nel caso ci sia un errore all’interno di una Custom Activity, il compilatore lo segnala ovunque tale activity venga utilizzata. In pratica l’errore non è relativo al contesto. 

 

Async/Sync Activity

Per creare Activity Asincrone bisogna derivare la Custom Activity da AsyncCodeActivity e non da CodeActivity. 

 

Try/Catch

Il ramo FINALLY dell’Activity Try/Catch non si comporta come l’omonima istruzione dei linguaggi: praticamente viene eseguita solo se viene eseguito il blocco try o uno dei blocchi catch. Se si verifica un’eccezione non catturata, neanche il Finally verrà eseguito causando l’Abort del Flow. Nel caso di Fault da Servizio (Send/Recive Activity) l’attuale implementazione dell’Activity di Try/Catch è in grado di gestire solo la base class FaultExeception e non la generica FaultEception<MyFault>. Se si prova a catturare quest’ultima l’eccezione verrà propagata.

 

Suggerimento: se si è anche autori del servizio che può generare il Fault, utilizzare uno dei parametri standard di FaultException (ad esempio Action) per individuare l’eccezione specifica.

Known Type

Se si prova ad impostare una Receive un message type root di una gerarchia di oggetti (nell’es. precedente: Forma), bisogna poi utilizzare proprio un oggetto Forma e non uno dei suoi figli. Neanche il downcasting aggira questo problema perché il messaggio ottenuto dalla serializzazione dello stesso ha un elemento di Root diverso che porta la Receive a scartarlo.  

 

L’unica soluzione trova è quella di avere uno Switch con n. Receive/SendReplay.

La cosa si applica anche alla Send/ReceiveReplay

Rinominare i File

Rinominando i file XAML e XAMLX non sempre Visual Studio effettua un refactory completo. Infatti il file continua a mantenere memorizzato il nome del file originale, cosa che va corretta a mano dalla modalità Code (F7).

Saltando questo passaggio il framework presenta errori alquanto ambigui e forvianti.

 

Es: se si crea un’activity (xaml), la si rinomina e non si corregge quanto appena detto, richiamandola da un WFServices si ottiene un errore di Endpoint non presente, che non c’entra assolutamente nulla.

Refactoring

Se viene effettuato il refactoring di oggetti utilizzati all’interno di file XAMLX o XAMAL, ad esempio rinominando il nome, l’azione non si ripercuote automaticamente. Bisogna quindi procedere manualmente alla modifica, spesso dalla modalità Code (F7), poiché il designer segnale errori che non permettono di visualizzare il flusso.

 

Suggerimento: utilizzare versioni quanto più stabili possibili di oggetti (data contract) e namespace definitivi, altrimenti ogni modifica è un vero e proprio grattacapo.

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme