Condividi tramite


Problemi noti relativi all'aggiornamento di applicazioni e artefatti

Aggiornamento di un'applicazione

La rimozione o l'eliminazione di un artefatto non la rimuove da tutte le posizioni

La rimozione o l'eliminazione di un artefatto lo elimina dai database BizTalk Server, in modo che non venga più visualizzato nella console di amministrazione o nell'elenco di artefatti per un'applicazione generata dal comando BTSTask ListApp. Non rimuove l'artefatto dal Registro di sistema di Windows, dalla Global Assembly Cache (GAC), da una directory virtuale o dal file system, se presente in uno di questi percorsi. Nel caso di porte di trasmissione, gruppi di porte di trasmissione, porte di ricezione e percorsi di ricezione, che esistono solo nel database di gestione BizTalk, questa operazione elimina completamente l'artefatto.

Aggiornamento di un elemento

La rimozione o la modifica dello stato di un artefatto possono impedire il funzionamento di un'applicazione

Quando si aggiunge un riferimento da un'applicazione a un'altra e si apportano modifiche allo stato di un artefatto da cui dipende un'altra applicazione oppure si rimuove l'artefatto, l'applicazione con la dipendenza non funzionerà correttamente. Per altre informazioni sulla modifica dello stato di un artefatto, vedere la sezione relativa all'artefatto appropriato in Gestione degli artefatti (https://go.microsoft.com/fwlink/?LinkID=154725).

I file di criteri .NET non sono supportati

L'uso dei file di criteri .NET non è supportato in BizTalk Server. Ciò è dovuto al fatto che un file di criteri potrebbe non funzionare come previsto. I file di criteri reindirizzano .NET a una versione di assembly specificata nella GAC, ma BizTalk Server accede spesso agli assembly e ai dati degli artefatti da una cache o dal database di gestione BizTalk. A seconda del tipo di artefatto, della situazione di memorizzazione nella cache e del riavvio delle istanze host, il file dei criteri potrebbe non eseguire le operazioni desiderate.

Aggiornamento di un assemblaggio

Le modifiche apportate a un assembly potrebbero non essere effettive se l'host non viene arrestato

Gli assembly BizTalk devono seguire le regole di controllo delle versioni di .NET. L'implicazione principale di questo è che un progetto BizTalk, una volta compilato su una determinata versione di un altro progetto o assembly .NET (inclusi i progetti BizTalk), continua a usare tale versione fino a quando non viene ricompilato rispetto a una versione più recente.

Un problema comune si verifica durante lo sviluppo correlato al controllo delle versioni di .NET quando i numeri di versione in un progetto BizTalk non vengono modificati e l'assembly viene ridistribuito senza arrestare e avviare l'istanza host BizTalk in cui vengono caricati i tipi.

Quando il processo viene eseguito di nuovo, le modifiche non diventano effettive. Ciò è dovuto al modo in cui gli assembly .NET vengono caricati in memoria. Poiché l'host dispone già di una copia in memoria dell'assembly, non ricarica l'assembly quando viene inserita una nuova copia nella Global Assembly Cache (GAC). Ad esempio, se la versione 1.0.0.0 di un assembly con un'orchestrazione viene distribuita ed eseguita e le modifiche vengono apportate all'orchestrazione, ma il numero di versione non viene modificato, le modifiche non diventano effettive. Dopo che l'istanza host viene arrestata, la copia in memoria dell'assembly viene rilasciata. Quando l'istanza host viene riavviata, ricarica la nuova copia dell'assembly e riceve le modifiche. Se è stata distribuita una nuova versione, ad esempio la versione 2.0.0.0 e è stata caricata, le modifiche sarebbero effettive.

La modifica della versione dell'assembly può interrompere la relazione tra un assembly e gli elementi che vi fanno riferimento in base alla versione

Nello sviluppo di .NET Framework è in genere necessario aggiornare il numero di versione dell'assembly al numero di build corrente quando viene eseguita una compilazione. Tuttavia, quando si sviluppa una soluzione BizTalk, la modifica del numero di versione dell'assembly può interrompere la relazione tra un assembly e gli elementi dipendenti che fanno riferimento alla DLL in base al numero di versione dell'assembly. Nella tabella seguente sono elencati gli elementi che fanno riferimento a un assembly BizTalk Server usando il relativo numero di versione e l'effetto della modifica di un numero di versione dell'assembly.

Entità Effetto della modifica del numero di versione dell'assembly
File di legatura La modifica del numero di versione dell'assembly causa l'esito negativo di tutti i file di associazione esistenti che fanno riferimento all'assembly. Questo avviene perché il file di associazione fa riferimento all'assembly in base agli attributi, incluso il relativo numero di versione.

È possibile aggiornare le informazioni sulla versione nel file di associazione usando Blocco note o un altro editor. È anche possibile ridistribuire la soluzione e quindi rigenerare il file di associazione usando la console di amministrazione di BizTalk Server. Infine, è possibile usare gli script per automatizzare la distribuzione e il controllo delle versioni. Per altre informazioni sulla distribuzione, vedere Distribuzione e gestione di applicazioni BizTalk (https://go.microsoft.com/fwlink/?LinkID=154210).
File di definizione del profilo di tracciamento BAM (.btt) La modifica del numero di versione dell'assembly causa il fallimento di tutti i file di definizione del profilo di monitoraggio BAM esistenti. I file di rilevamento BAM sono in un formato di file binario, pertanto non possono essere modificati e devono essere rigenerati. Se sono necessari profili di rilevamento BAM, potrebbe essere necessario eseguire una delle operazioni seguenti:

- Evitare di aggiornare frequentemente i numeri di versione durante il processo di compilazione
- Ritardare la compilazione dei profili di rilevamento BAM fino a quando i numeri di versione non sono stabili
Servizi Web pubblicati tramite il Wizard di Pubblicazione Servizi Web Quando viene utilizzata la Creazione guidata di servizi Web per produrre un'interfaccia Web ASP.NET, la versione dell'assembly di BizTalk Server viene inclusa nel codice sorgente ASP.NET. Il numero di versione dell'assembly viene usato in fase di esecuzione dall'interfaccia ASP.NET come parte della proprietà bodyTypeAssemblyQualifiedName dell'operazione del servizio Web. Se il numero di versione dell'assembly BizTalk Server viene modificato senza aggiornare la proprietà bodyTypeAssemblyQualifiedName, le successive operazioni del servizio Web verranno rifiutate da BizTalk Server.

Se il percorso di ricezione usa XmlDefaultPipeline, la sottoscrizione si basa sul tipo di documento. Usa le informazioni sull'assembly incorporato e fallirà se l'assembly non è disponibile. Se si usa il PassThruPipeline, che è l'impostazione predefinita se si espone una porta e si permette alla procedura guidata di creare la posizione di ricezione, la sottoscrizione ignora le informazioni sull'assembly incorporato.