Cosa significa questo errore WCF: “Avviso strumento personalizzato: imansible importare wsdl: portType”

Ho creato un progetto di libreria di servizi WCF nella mia soluzione e ho riferimenti di servizio a questo. Uso i servizi da una libreria di classi, quindi ho riferimenti dal mio progetto di applicazione WPF oltre alla libreria di classi. I servizi vengono impostati in modo diretto, solo modificati per ottenere funzioni di servizio asincrone.

Tutto andava bene, fino a quando non volevo aggiornare i miei riferimenti di servizio. Ha fallito, quindi alla fine sono tornato indietro e ho ripreso, ma non è riuscito nemmeno allora! Pertanto, l’aggiornamento dei riferimenti ai servizi non ha esito positivo senza apportare modifiche. Perché?!

L’errore che ottengo è questo:

Custom tool error: Failed to generate code for the service reference 'MyServiceReference'. Please check other error and warning messages for details. 

L’avviso fornisce ulteriori informazioni:

 Custom tool warning: Cannot import wsdl:portType Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Error: List of referenced types contains more than one type with data contract name 'Patient' in namespace 'http://schemas.datacontract.org/2004/07/MyApp.Model'. Need to exclude all but one of the following types. Only matching types can be valid references: "MyApp.Dashboard.MyServiceReference.Patient, Medski.Dashboard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" (matching) "MyApp.Model.Patient, MyApp.Model, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" (matching) XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType[@name='ISomeService'] 

Ci sono anche due avvertimenti simili che dicono:

 Custom tool warning: Cannot import wsdl:binding Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on. XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType[@name='ISomeService'] XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_ISomeService'] 

E lo stesso per:

 Custom tool warning: Cannot import wsdl:port .. 

Trovo tutto questo confuso .. Non ho una class Patient sul Dashboard lato client tranne quella che ho ottenuto attraverso il riferimento del servizio. Quindi cosa vuol dire? E perché improvvisamente mostra? Ricorda: non ho nemmeno cambiato nulla!

Ora, la soluzione a questo è stata trovata qui , ma senza una spiegazione di ciò che significa. Così; nel “Configura riferimento servizio” per il servizio deseleziono la casella di controllo “Riusa i tipi negli assiemi di riferimento”. Ribuild ora funziona tutto senza problemi. Ma cosa ho davvero cambiato? Questo avrà un impatto sulla mia applicazione? E quando si dovrebbe deselezionare questo? Voglio riutilizzare i tipi che ho configurato DataContract, ma non di più. Avrò ancora accesso a quelli senza questo selezionato?

Quando aggiungi un riferimento al servizio, ci sono due modi in cui i tipi utilizzati dal servizio possono essere gestiti:

  • I tipi sono memorizzati in una DLL e tale DLL viene referenziata dal client e dall’applicazione server.
  • I tipi non sono in una DLL a cui fa riferimento il client. In tal caso lo strumento che crea il riferimento al servizio creerà i tipi nel file references.cs.

Ci sono molte cose che possono andare storte. Abbiamo scoperto che se lo strumento si blocca, a volte è più veloce eliminare il riferimento al servizio e ricominciare.

Abbiamo smesso di utilizzare il riferimento del servizio. Per i progetti in cui abbiamo il controllo del cliente e del servizio, utilizziamo il metodo descritto in questo screencast .

Ho trovato la mia risposta qui: http://www.lukepuplett.com/2010/07/note-to-self-don-let-wcf-svcutil-reuse.html

Per farla breve: ho deselezionato Riutilizzare i tipi negli assembly di riferimento dal menu Avanzate .


Non so se questo è importante ma non sto usando MVC, ma Web Forms.

Ho anche avuto questo problema oggi. Mi ci è voluto un giorno intero per trovare il mio errore. Spero che sia d’aiuto.

La mia class che non è stato ansible importare ha una proprietà di tipo cut-enum. Questa proprietà è contrassegnata come DataMember e Enum viene anche contrassegnato come DataContract. Tutto bene finora. Ho appena dimenticato di contrassegnare ogni membro di enum come EnumMember.

Quindi ho cambiato

 [DataContract] public enum SortMethodType { Default = 0, Popularity = 1, ReleaseDate = 2, PublishedDate = 3, TranslatedTitle = 4, OriginalTitle = 5, UserRating = 6, Duration = 7 } 

A questa:

 [DataContract] public enum SortMethodType { [EnumMember] Default = 0, [EnumMember] Popularity = 1, [EnumMember] ReleaseDate = 2, [EnumMember] PublishedDate = 3, [EnumMember] TranslatedTitle = 4, [EnumMember] OriginalTitle = 5, [EnumMember] UserRating = 6, [EnumMember] Duration = 7 } 

E alla fine ha funzionato!

potrebbe sembrare strano, ma l’ho risolto eliminando i riferimenti, quindi chiudendo Visual Studio e riaprendendolo di nuovo e infine aggiungendo di nuovo i riferimenti.

Penso che la cosa dello strumento personalizzato debba essere riavviata o qualcosa del genere.

Vai a Proprietà avanzate durante l’aggiunta di riferimento e rimuovere “System.Window.Browser” dalla lista di controllo, Risolve il problema.

Ricevo costantemente questo errore mentre funziona su un’altra macchina per sviluppatori. Anche se sono un amministratore completo ovunque nella mia macchina virtuale, ho provato a chiudere Visual Studio e riaprirlo con “Esegui come amministratore” e ha funzionato magicamente.

In bocca al lupo.

Uno svantaggio di distriggersre i tipi di riutilizzo negli assembly referenziati è che può causare problemi con riferimenti ambigui. Ciò è dovuto al riferimento del servizio che crea nuovamente tali oggetti nel file .cs di riferimento e il codice che implementa il servizio potrebbe farli riferimento dallo spazio dei nomi originale.

Quando si verifica questo scenario, trovo utile controllare i ‘tipi di riutilizzo in assembly referenziati specificati’ che mi consentono di scegliere quelli con solo riferimenti ambigui, che risolvono il problema rapidamente in questo modo.

Spero che aiuti qualcun altro.

Ho ricevuto l’avviso dopo aver aggiornato la mia soluzione da Visual Studio (VS) 2010 al 2013 e modificato il framework .NET di ciascun progetto da 4 a 4.5.1. Ho chiuso VS e riaperto e gli avvertimenti sono andati via.

Le mie interfacce del servizio WCF sono in un assembly, l’implementazione è in un altro e il riferimento del servizio si trova in un altro assembly, separato dai client del riferimento del servizio. Ho ricevuto il messaggio di errore subito dopo aver applicato DataContract a un enum. Dopo aver applicato EnumMember ai campi dell’enumerazione, il problema è stato risolto.

In caso di dubbi sul fatto che il tuo servizio non abbia problemi (come problemi con enumerazioni o classi non serializzabili come menzionato da altri), prova a creare un nuovo progetto con un nuovo riferimento.

Sto usando Silverlight 5 e ho cercato di eliminare e ricreare il riferimento più volte. Il file reference.cs appena uscito completamente vuoto ogni volta ed erano passati letteralmente anni da quando l’avevo creato, quindi cercare di capire che cosa era cambiato nel servizio era fuori questione.

Ho notato che l’errore conteneva riferimenti a 2.0.5.0. Ora non so nemmeno se questo è realmente rilevante per la versione di Silverlight, ma mi ha fatto pensare solo a creare un nuovo progetto e poi improvvisamente tutto ha funzionato.

Avviso 2 Avviso strumento personalizzato: imansible importare wsdl: dettaglio portType: è stata generata un’eccezione durante l’esecuzione di un’estensione di importazione WSDL: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Errore: Imansible caricare il file o l’assembly ‘System.Xml, Versione = 2.0.5.0, Culture = neutral, PublicKeyToken = 7cec85d7bea7798e ‘o una delle sue dipendenze. Il sistema non trova il file specificato. XPath to Error Origine: // wsdl: definizioni [@targetNamespace = ”] / wsdl: port Type [@ name = ‘IShoppingCart’]

Stavo controllando il mio progetto e stavo avendo lo stesso problema. Si è rivelato essere diverse versioni della stessa DLL sul WCF rispetto al sito Web. Sito Web ha una versione più recente della DLL e il servizio faceva riferimento a una versione precedente della DLL. Una volta che erano tutti sincronizzati, tutto funzionava bene.

Ho sperimentato lo stesso errore. Ho faticato per quasi un giorno a cercare di scoprire cosa stesse andando storto. L’indizio per me erano gli avvertimenti che VS stava lanciando. Stava cercando di fare un qualche tipo di mapping su Yahoo.Yui.Compressor.dll, una libreria che avevo aggiunto e rimosso (perché ho deciso di non usarlo) un paio di giorni prima. Era scioccante perché la biblioteca non c’era, ma in qualche modo cercava di farvi riferimento.

Infine, ripristino questa DLL dal Cestino e quindi posso aggiornare correttamente il riferimento al servizio.

Per chiunque qui in futuro, ho avuto lo stesso errore ma causato da problemi di versione, in due modi diversi.

Ho due servizi WCF e due applicazioni client che comunicano tramite i riferimenti del servizio. Ho aggiornato un pacchetto nuget su entrambi i lati e ho provato ad aggiornare il riferimento al servizio e ho ricevuto questo errore.

L’eliminazione non ha aiutato. Deselezionare “riutilizzare assemblaggi” non è desiderato in quanto ho bisogno di riutilizzarli – questo è il punto.

Alla fine, c’erano due problemi separati:

1) Il primo numero, credo, era un problema di memorizzazione nella cache dello studio visivo. Ho esaminato meticolosamente tutti i riferimenti e non ho riscontrato problemi, ma ha comunque segnalato di non riuscire a trovare la versione precedente del file. Ho disinstallato tutti i pacchetti di nuget, riavviato Visual Studio e reinstallato. Aggiornamento del riferimento del servizio lavorato.

2) Il secondo problema è stato causato da un problema di dipendenza. Ho aggiornato il pacchetto nuget su entrambi i lati e tutto è apparso corretto, ma una dipendenza non contrassegnata era fuori sincrono. Esempio:

Pacchetto Foo v1 riferimenti Bar v1. È ansible aggiornare Foo e Bar in v2 in modo indipendente senza aggiornare il riferimento. Se si installa Foo e Bar v2, lo strumento di riferimento del servizio eseguirà la scansione di Foo v2, vedere il riferimento a Bar v1 e avrà esito negativo perché non riesce a trovare la versione precedente. Questo è segnalato solo correttamente se si aggiornano i numeri di versione della DLL per ogni pacchetto. Visual Studio e MSBuild non avranno problemi a sviluppare l’applicazione, ma il riferimento al servizio avrà un tempo terribile nel tentativo di risolvere tutto.

Spero che questo aiuti qualcuno.