Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Avviso
Questa documentazione non è per la versione più recente di SignalR. Dai un'occhiata a ASP.NET Core SignalR.
Questo documento descrive la risoluzione dei problemi comuni relativi a SignalR.
Versioni software usate in questo argomento
- Visual Studio 2013
- .NET 4.5
- SignalR versione 2
Versioni precedenti di questo argomento
Per informazioni sulle versioni precedenti di SignalR, vedere Versioni precedenti di SignalR.
Domande e commenti
Lasciare commenti e suggerimenti su come è piaciuta questa esercitazione e su cosa è possibile migliorare nei commenti nella parte inferiore della pagina. Se si hanno domande non direttamente correlate all'esercitazione, è possibile pubblicarle nel forum ASP.NET SignalR o StackOverflow.com.
Questo documento contiene le sezioni seguenti.
- La chiamata di metodi tra il client e il server ha esito negativo in modo invisibile all'utente
- Configurazione di websocket IIS per il ping/pong al fine di rilevare un client disconnesso
- Altri problemi di connessione
- Errori di compilazione e lato server
- Problemi di Visual Studio
- Problemi di Internet Information Services
- Problemi di Microsoft Azure
Le chiamate ai metodi tra il client e il server falliscono in modo silenzioso
In questa sezione vengono descritte le possibili cause dell'esito negativo di una chiamata al metodo tra client e server senza un messaggio di errore significativo. In un'applicazione SignalR il server non dispone di informazioni sui metodi implementati dal client; quando il server richiama un metodo client, i dati del nome del metodo e dei parametri vengono inviati al client e il metodo viene eseguito solo se esiste nel formato specificato dal server. Se nel client non viene trovato alcun metodo corrispondente, non viene generato alcun messaggio di errore nel server.
Per analizzare ulteriormente i metodi client che non vengono chiamati, è possibile attivare la registrazione prima di chiamare il metodo start nell'hub per vedere quali chiamate provengono dal server. Per abilitare la registrazione in un'applicazione JavaScript, consultare Come abilitare la registrazione lato client (versione client JavaScript). Per abilitare la registrazione in un'applicazione client .NET, vedere Come abilitare la registrazione lato client (versione client.NET).
Metodo errato, firma del metodo non corretto o nome dell'hub non corretto
Se il nome o la firma di un metodo chiamato non corrisponde esattamente a un metodo appropriato nel client, la chiamata avrà esito negativo. Verificare che il nome del metodo chiamato dal server corrisponda al nome del metodo nel client. SignalR crea anche il proxy hub utilizzando metodi con notazione camel case, come si usa in JavaScript, quindi un metodo chiamato SendMessage sul server verrebbe chiamato sendMessage nel proxy client. Se si usa l'attributo HubName nel codice lato server, verificare che il nome usato corrisponda al nome usato per creare l'hub nel client. Se non si usa l'attributo HubName, verificare che il nome dell'hub in un client JavaScript sia in camel-case, ad esempio "chatHub" anziché "ChatHub".
Nome del metodo duplicato nel client
Verificare di non disporre di un metodo duplicato nel client che differisce solo per caso. Se l'applicazione client ha un metodo denominato sendMessage, verificare che non sia presente anche un metodo denominato SendMessage .
Parser JSON mancante nel client
SignalR richiede che sia presente un parser JSON per serializzare le chiamate tra il server e il client. Se il client non ha un parser JSON predefinito (ad esempio Internet Explorer 7), è necessario includerne uno nell'applicazione. È possibile scaricare il parser JSON qui.
Combinazione della sintassi di Hub e PersistentConnection
SignalR usa due modelli di comunicazione: Hub e PersistentConnections. La sintassi per chiamare questi due modelli di comunicazione è diversa nel codice client. Se è stato aggiunto un hub nel codice del server, verificare che tutto il codice client usi la sintassi dell'hub appropriata.
Codice client JavaScript che crea un oggetto PersistentConnection in un client JavaScript
var myConnection = $.connection('/echo');
Codice client JavaScript che crea un proxy hub in un client Javascript
var myHub = $.connection.MyHub;
Codice del server C# che esegue il mapping di una route a un PersistentConnection
RouteTable.Routes.MapConnection<MyConnection>("my", "/echo");
Codice del server C# che esegue il mapping di una route a un hub o a più hub se sono presenti più applicazioni
App.MapSignalR();
Connessione avviata prima dell'aggiunta delle sottoscrizioni
Se la connessione dell'hub viene avviata prima che i metodi che possono essere chiamati dal server vengano aggiunti al proxy, i messaggi non verranno ricevuti. Il codice JavaScript seguente non avvierà correttamente l'hub:
Codice client JavaScript non corretto che non consentirà la ricezione dei messaggi hub
var chat = $.connection.chatHub;
$.connection.hub.start().done(function () {
chat.client.broadcastMessage = function (name, message) {...};
});
Aggiungere invece le sottoscrizioni del metodo prima di chiamare Start:
Codice client JavaScript che aggiunge correttamente sottoscrizioni a un hub
var chat = $.connection.chatHub;
chat.client.broadcastMessage = function (name, message) {...};
$.connection.hub.start().done(function () {
...
});
Nome del metodo mancante nel proxy hub
Verificare che il metodo definito nel server sia sottoscritto nel client. Anche se il server definisce il metodo, deve comunque essere aggiunto al proxy client. I metodi possono essere aggiunti al proxy client nei modi seguenti (si noti che il metodo viene aggiunto al client membro dell'hub, non direttamente all'hub):
Codice client JavaScript che aggiunge metodi a un proxy hub
// Method added to proxy in JavaScript:
myHubProxy.server.method1 = function (param1, param2) {...};
//Multiple methods added to proxy in JavaScript using jQuery:
$.extend(myHubProxy.server, {
method1: function (param1, param2) {...},
method2: function (param3, param4) {...}
});
Metodi hub o hub non dichiarati come pubblici
Per essere visibile nel client, l'implementazione e i metodi dell'hub devono essere dichiarati come public.
Accesso all'hub da un'applicazione diversa
È possibile accedere agli hub SignalR solo tramite applicazioni che implementano client SignalR. SignalR non può interagire con altre librerie di comunicazione, ad esempio servizi Web SOAP o WCF. Se non è disponibile alcun client SignalR per la piattaforma di destinazione, non è possibile accedere direttamente all'endpoint del server.
Serializzazione manuale dei dati
SignalR userà automaticamente JSON per serializzare i parametri del metodo. Non è necessario eseguire questa operazione manualmente.
Metodo dell'hub remoto non eseguito nel client nella funzione OnDisconnected
Questo comportamento è predefinito. Quando OnDisconnected viene chiamato, l'hub ha già immesso lo Disconnected stato, che non consente di chiamare altri metodi hub.
Codice del server C# che esegue correttamente il codice nell'evento OnDisconnected
public class MyHub : Hub
{
public override Task OnDisconnected()
{
// Do what you want here
return base.OnDisconnected();
}
}
OnDisconnect non viene attivato in momenti coerenti
Questo comportamento è predefinito. Quando un utente tenta di allontanarsi da una pagina con una connessione SignalR attiva, il client SignalR eseguirà quindi un tentativo ottimale di notificare al server che la connessione client verrà arrestata. Se il miglior tentativo del client SignalR non riesce a raggiungere il server, il server eliminerà la connessione dopo un intervallo configurabile DisconnectTimeout, momento in cui verrà attivato l'evento OnDisconnected. Se il tentativo migliore del client SignalR ha esito positivo, l'evento OnDisconnected verrà generato immediatamente.
Per informazioni sull'impostazione dell'impostazione DisconnectTimeout , vedere Gestione degli eventi di durata della connessione: DisconnectTimeout.
Limite di connessione raggiunto
Quando si usa la versione completa di IIS in un sistema operativo client come Windows 7, viene imposto un limite di 10 connessioni. Quando si usa un sistema operativo client, usare IIS Express per evitare questo limite.
Connessione tra domini non configurata correttamente
Se una connessione tra domini (una connessione per cui l'URL signalR non si trova nello stesso dominio della pagina di hosting) non è configurata correttamente, la connessione potrebbe non riuscire senza un messaggio di errore. Per informazioni su come abilitare la comunicazione tra domini, vedere Come stabilire una connessione tra domini.
Connessione che usa NTLM (Active Directory) non funziona nel client .NET
Una connessione in un'applicazione client .NET che usa la sicurezza del dominio potrebbe non riuscire se la connessione non è configurata correttamente. Per usare SignalR in un ambiente di dominio, impostare la proprietà di connessione necessaria come indicato di seguito:
Codice client C# che implementa le credenziali di connessione
connection.Credentials = CredentialCache.DefaultCredentials;
Configurazione dei websocket IIS per eseguire il ping/pong al fine di rilevare un client disconnesso.
I server SignalR non sanno se il client è inattivo o meno e si basano sulla notifica dal websocket sottostante per gli errori di connessione, ovvero il OnClose callback. Una soluzione a questo problema consiste nel configurare websocket IIS per eseguire automaticamente il ping/pong. In questo modo si garantisce che la connessione venga chiusa in caso di interruzione imprevista. Per altre informazioni, vedere questo post di stackoverflow.
Altri problemi di connessione
In questa sezione vengono descritte le cause e le soluzioni per sintomi o messaggi di errore specifici che si verificano durante una connessione.
Errore "Start deve essere chiamato prima che i dati possano essere inviati"
Questo errore viene comunemente rilevato se il codice fa riferimento agli oggetti SignalR prima dell'avvio della connessione. Una volta completata la connessione, è necessario aggiungere il collegamento per i gestori e simili che chiameranno i metodi definiti sul server. Si noti che la chiamata a Start è asincrona, quindi il codice dopo la chiamata può essere eseguito prima del completamento. Il modo migliore per aggiungere gestori dopo l'avvio completo di una connessione consiste nell'inserirli in una funzione di callback passata come parametro al metodo start:
Codice client JavaScript che aggiunge correttamente gestori eventi che fanno riferimento a oggetti SignalR
$.connection.hub.start().done(function () {
// Wire up Send button to call NewContosoChatMessage on the server.
$('#newContosoChatMessage').click(function () {
contosoChatHubProxy.server.newContosoChatMessage(
$('#displayname').val(), $('#message').val());
$('#message').val('').focus();
});
Questo errore verrà visualizzato anche se una connessione si arresta mentre viene ancora fatto riferimento agli oggetti SignalR.
Errore "301 Spostato in modo permanente" o "302 Spostato temporaneamente"
Questo errore può essere visualizzato se il progetto contiene una cartella denominata SignalR, che interferisce con il proxy creato automaticamente. Per evitare questo errore, non usare una cartella denominata SignalR nell'applicazione o disattivare la generazione automatica del proxy. Per altri dettagli, vedere Il proxy generato e le relative funzionalità .
Errore "403 Accesso negato" nel client .NET o Silverlight
Questo errore può verificarsi in ambienti tra domini in cui la comunicazione tra domini non è abilitata correttamente. Per informazioni su come abilitare la comunicazione tra domini, vedere Come stabilire una connessione tra domini. Per stabilire una connessione tra domini in un client Silverlight, vedere Connessioni tra domini dai client Silverlight.
Errore "404 Non trovato"
Esistono diverse cause per questo problema. Verificare tutti gli elementi seguenti:
Riferimento all'indirizzo proxy dell'hub non formattato correttamente: Questo errore viene comunemente rilevato se il riferimento all'indirizzo proxy dell'hub generato non è formattato correttamente. Verificare che il riferimento all'indirizzo dell'hub sia stato eseguito correttamente. Per informazioni dettagliate, vedere Come fare riferimento al proxy generato dinamicamente .
Aggiungere percorsi all'applicazione prima di inserire il percorso dell'hub: Se l'applicazione utilizza altri percorsi, verificare che il primo percorso aggiunto sia la chiamata a
MapSignalR.Uso di IIS 7 o 7.5 senza l'aggiornamento per gli URL senza estensione: L'uso di IIS 7 o 7.5 richiede un aggiornamento per gli URL senza estensione in modo che il server possa fornire l'accesso alle definizioni dell'hub all'indirizzo
/signalr/hubs. L'aggiornamento è disponibile qui.Cache IIS non aggiornata o danneggiata: Per verificare che il contenuto della cache non sia obsoleto, immettere il comando seguente in una finestra di PowerShell per cancellare la cache:
net stop w3svc Remove-Item -Path "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\*" -Force -Recurse net start w3svc
"500 Errore interno del server"
Si tratta di un errore molto generico che potrebbe avere un'ampia gamma di cause. I dettagli dell'errore dovrebbero essere visualizzati nel registro eventi del server oppure sono disponibili tramite il debug del server. È possibile ottenere informazioni più dettagliate sull'errore attivando i dettagli degli errori sul server. Per altre informazioni, vedere Come gestire gli errori nella classe Hub.
Questo errore viene comunemente rilevato anche se un firewall o un proxy non è configurato correttamente, causando la riscrittura delle intestazioni della richiesta. La soluzione consiste nel assicurarsi che la porta 80 sia abilitata nel firewall o nel proxy.
"Codice di risposta imprevisto: 500"
Questo errore può verificarsi se la versione di .NET Framework usata nell'applicazione non corrisponde alla versione specificata in Web.Config. La soluzione consiste nel verificare che .NET 4.5 venga usato sia nelle impostazioni dell'applicazione che nel file Web.Config.
Errore "TypeError: <hubType> è indefinito"
Questo errore genererà se la chiamata a MapSignalR non viene eseguita correttamente. Per altre informazioni, vedere Come registrare il middleware SignalR e configurare le opzioni di SignalR .
JsonSerializationException non è stato gestito dal codice utente
Verificare che i parametri inviati ai metodi non includano tipi non serializzabili, ad esempio handle di file o connessioni di database. Se è necessario usare i membri in un oggetto lato server che non si vuole inviare al client (per motivi di sicurezza o per motivi di serializzazione), usare l'attributo JSONIgnore .
Errore "Errore del protocollo: Trasporto sconosciuto"
Questo errore può verificarsi se il client non supporta i trasporti usati da SignalR. Vedere Trasporti e fallback per informazioni su quali browser possono essere usati con SignalR.
"La generazione del proxy dell'hub JavaScript è stata disabilitata".
Questo errore si verificherà se DisableJavaScriptProxies è impostato anche includendo un riferimento al proxy generato dinamicamente in signalr/hubs. Per altre informazioni sulla creazione manuale del proxy, vedere Il proxy generato e le operazioni eseguite automaticamente.
"L'ID connessione è in formato non corretto" o "L'identità utente non può cambiare durante una connessione SignalR attiva"
Questo errore può essere visualizzato se viene usata l'autenticazione e il client viene disconnesso prima dell'arresto della connessione. La soluzione consiste nell'arrestare la connessione SignalR prima di disconnettere il client.
"Errore non rilevato: SignalR: jQuery non trovato. Assicurati che jQuery sia referenziato prima del file SignalR.js" error
Il client JavaScript SignalR richiede l'esecuzione di jQuery. Verificare che il riferimento a jQuery sia corretto, che il percorso usato sia valido e che il riferimento a jQuery sia prima del riferimento a SignalR.
Errore "TypeError non rilevato: Impossibile leggere la proprietà '<property>' di undefined"
Questo errore si verifica a causa della mancanza di jQuery o di un riferimento corretto al proxy hubs. Verificare che il riferimento a jQuery e il proxy hubs sia corretto, che il percorso usato sia valido e che il riferimento a jQuery sia prima del riferimento al proxy hubs. Il riferimento predefinito al proxy hub dovrebbe essere simile al seguente:
Codice lato client HTML che fa riferimento correttamente al proxy Hubs
<script src="/signalr/hubs"></script>
Errore "RuntimeBinderException non gestito dal codice utente"
Questo errore può verificarsi quando viene utilizzato l'overload non corretto di Hub.On . Se il metodo ha un valore restituito, il tipo restituito deve essere specificato come parametro di tipo generico:
Metodo definito nel client (senza proxy generato)
MyHub.On<ReturnType>("MethodName", LocalMethod);
L'ID connessione è incoerente o la connessione si interrompe tra i caricamenti di pagine.
Questo comportamento è predefinito. Poiché l'oggetto hub è ospitato nell'oggetto pagina, l'hub viene eliminato definitivamente quando la pagina viene aggiornata. Un'applicazione a più pagine deve mantenere l'associazione tra gli utenti e gli ID di connessione in modo che siano coerenti tra i caricamenti di pagina. Gli ID di connessione possono essere archiviati nel server in un ConcurrentDictionary oggetto o in un database.
Errore "Il valore non può essere null"
I metodi lato server con parametri facoltativi non sono attualmente supportati; se il parametro facoltativo viene omesso, il metodo avrà esito negativo. Per altre informazioni, vedere Parametri facoltativi.
Errore "Firefox non è in grado di stabilire una connessione al server all'indirizzo<>" in Firebug
Questo messaggio di errore può essere visualizzato in Firebug se la negoziazione del trasporto WebSocket ha esito negativo e viene invece utilizzato un altro trasporto. Questo comportamento è predefinito.
Errore "Il certificato remoto non è valido in base alla procedura di convalida" nell'applicazione client .NET
Se il server richiede certificati client personalizzati, è possibile aggiungere un certificato x509certificate alla connessione prima che venga effettuata la richiesta. Aggiungere il certificato alla connessione usando Connection.AddClientCertificate.
La connessione viene eliminata dopo il timeout dell'autenticazione
Questo comportamento è predefinito. Le credenziali di autenticazione non possono essere modificate mentre una connessione è attiva; per aggiornare le credenziali, la connessione deve essere arrestata e riavviata.
OnConnected viene chiamato due volte quando si usa jQuery Mobile
La funzione di initializePage jQuery Mobile forza l'esecuzione degli script in ogni pagina nuovamente, creando così una seconda connessione. Le soluzioni per questo problema includono:
- Includere il riferimento a jQuery Mobile prima del file JavaScript.
- Disabilitare la
initializePagefunzione impostando$.mobile.autoInitializePage = false. - Attendere il completamento dell'inizializzazione della pagina prima di avviare la connessione.
I messaggi vengono ritardati nelle applicazioni Silverlight tramite eventi inviati dal server
I messaggi vengono ritardati quando si usano gli eventi inviati dal server in Silverlight. Per forzare l'uso del *long polling*, utilizzare il seguente comando all'avvio della connessione:
connection.Start(new LongPollingTransport());
"Autorizzazione negata" con il protocollo Forever Frame
Si tratta di un problema noto, descritto qui. Questo sintomo può essere visto usando la libreria JQuery più recente; la soluzione alternativa consiste nel effettuare il downgrade dell'applicazione a JQuery 1.8.2.
"InvalidOperationException: richiesta web socket non valida.
Questo errore può verificarsi se viene usato il protocollo WebSocket, ma il proxy di rete sta modificando le intestazioni della richiesta. La soluzione consiste nel configurare il proxy per consentire WebSocket sulla porta 80.
Eccezione: <nome del metodo> non è stato possibile risolvere quando il client chiama il metodo sul server
Questo errore può derivare dall'uso di tipi di dati che non possono essere individuati in un payload JSON, ad esempio Array. La soluzione alternativa consiste nell'usare un tipo di dati individuabile da JSON, ad esempio IList. Per altre informazioni, vedere .NET Client non è in grado di chiamare i metodi dell'hub con parametri di matrice.
Errori di compilazione e lato server
La sezione seguente contiene le possibili soluzioni agli errori di runtime sul lato server e del compilatore.
Il riferimento all'istanza dell'hub è Null
Poiché viene creata un'istanza dell'hub per ogni connessione, non è possibile creare manualmente un'istanza di un hub nel codice. Per chiamare i metodi in un hub dall'esterno dell'hub stesso, vedere Come chiamare i metodi client e gestire i gruppi dall'esterno della classe Hub per ottenere un riferimento al contesto dell'hub.
HTTPContext.Current.Session è Null
Questo comportamento è predefinito. SignalR non supporta lo stato della sessione ASP.NET, poiché l'abilitazione dello stato della sessione interrompe la messaggistica duplex.
Nessun metodo appropriato per eseguire l'override
Questo errore può essere visualizzato se si usa il codice della documentazione o dei blog meno recenti. Verificare di non fare riferimento ai nomi dei metodi modificati o deprecati ,ad esempio OnConnectedAsync.
HostContextExtensions.WebSocketServerUrl è null
Questo comportamento è predefinito. Questo membro è deprecato e non deve essere utilizzato.
Errore "Una route denominata 'signalr.hubs' è già presente nella raccolta di route"
Questo errore verrà visualizzato se MapSignalR viene chiamato due volte dall'applicazione. Alcune applicazioni di esempio chiamano MapSignalR direttamente nella classe Startup; altre effettuano la chiamata in una classe wrapper. Assicurarsi che l'applicazione non faccia entrambe le operazioni.
WebSocket non viene usato
Se si è verificato che il server e i client soddisfino i requisiti per WebSocket (elencati nel documento Piattaforme supportate ), sarà necessario abilitare WebSocket nel server. Le istruzioni per eseguire questa operazione sono disponibili qui.
$.connection non è definito
Questo errore indica che gli script in una pagina non vengono caricati correttamente oppure il proxy hub non è raggiungibile o non è accessibile in modo errato. Verificare che i riferimenti allo script nella pagina corrispondano agli script caricati nel progetto e che sia possibile accedere a /signalr/hub in un browser quando il server è in esecuzione.
Impossibile trovare uno o più tipi necessari per compilare un'espressione dinamica
Questo errore indica che la Microsoft.CSharp libreria è mancante. Aggiungilo nella scheda Assemblies->Framework.
Non è possibile accedere allo stato del chiamante da Clients.Caller in Visual Basic o in un hub fortemente tipizzato; errore "La conversione dal tipo 'Task(Of Object)' al tipo 'String' non è valida"
Per accedere allo stato del chiamante in Visual Basic o in un hub fortemente tipizzato, usare la Clients.CallerState proprietà (introdotta in SignalR 2.1) anziché Clients.Caller.
Problemi di Visual Studio
Questa sezione descrive i problemi riscontrati in Visual Studio.
Il nodo Documenti script non viene visualizzato in Esplora soluzioni
Alcuni dei nostri tutorial indirizzano l'utente al nodo "Documenti script" in Esplora Soluzioni durante il debug. Questo nodo viene prodotto dal debugger JavaScript e verrà visualizzato solo durante il debug dei client del browser in Internet Explorer; il nodo non verrà visualizzato se vengono utilizzati Chrome o Firefox. Il debugger JavaScript non verrà eseguito anche se è in esecuzione un altro debugger client, ad esempio il debugger silverlight.
SignalR non funziona in Visual Studio 2008 o versioni precedenti
Questo comportamento è predefinito. SignalR richiede .NET Framework 4 o versione successiva; Ciò richiede che le applicazioni SignalR vengano sviluppate in Visual Studio 2010 o versione successiva. Il componente server di SignalR richiede .NET Framework 4.5.
Problemi di IIS
Questa sezione contiene problemi con Internet Information Services.
SignalR funziona nel server di sviluppo di Visual Studio, ma non in IIS
SignalR è supportato in IIS 7.0 e 7.5, ma è necessario aggiungere il supporto per gli URL senza estensione. Per aggiungere il supporto per gli URL senza estensione, vedere https://support.microsoft.com/kb/980368
SignalR richiede ASP.NET da installare nel server (ASP.NET non è installato in IIS per impostazione predefinita). Per installare ASP.NET, vedere download di ASP.NET.
Problemi di Microsoft Azure
Questa sezione contiene problemi con Microsoft Azure.
FileLoadException quando si ospita SignalR in un ruolo di lavoro di Azure
L'hosting di SignalR in un ruolo di lavoro di Azure potrebbe causare l'eccezione "Impossibile caricare il file o l'assembly 'Microsoft.Owin, Version=2.0.0.0". Si tratta di un problema noto con NuGet; i reindirizzamenti di binding non vengono aggiunti automaticamente nei progetti Ruolo di lavoro di Azure. Per risolvere questo problema, è possibile aggiungere manualmente i reindirizzamenti di binding. Aggiungere le righe seguenti al app.config file per il progetto Worker Role.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I messaggi non vengono ricevuti tramite il backplane di Azure dopo aver modificato i nomi degli argomenti
Gli argomenti usati dal backplane di Azure vengono gestiti internamente; non devono essere configurabili dall'utente.