Qué significa este error WCF: “Advertencia de herramienta personalizada: no se puede importar wsdl: portType”

Creé un proyecto de biblioteca de servicio WCF en mi solución y tengo referencias de servicio a esto. Utilizo los servicios de una biblioteca de clases, así que tengo referencias de mi proyecto de aplicación WPF además de la biblioteca de clases. Los servicios se configuran directamente: solo cambian para obtener funciones de servicio asincrónicas.

Todo funcionaba bien, hasta que quise actualizar mis referencias de servicio. Falló, así que finalmente retrocedí y lo reintenté, ¡pero falló incluso entonces! Entonces, la actualización de las referencias del servicio falla sin realizar ningún cambio en ella. ¡¿Por qué?!

El error que recibo es este:

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

La advertencia brinda más información:

 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'] 

También hay dos advertencias similares que dicen:

 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'] 

Y lo mismo para:

 Custom tool warning: Cannot import wsdl:port .. 

Encuentro que todo esto es confuso. No tengo una clase de pacientes en el panel del lado del cliente, excepto la que recibí a través de la referencia del servicio. Así que, ¿qué significa? ¿Y por qué se muestra de repente? Recuerda: ¡ni siquiera cambié nada!

Ahora, la solución a esto se encontró aquí , pero sin una explicación de lo que esto significa. Asi que; en “Configurar referencia de servicio” para el servicio, desmarcaré la casilla “Reutilizar tipos en los ensamblados a los que se hace referencia”. Reconstrucción ahora todo funciona bien sin problemas. ¿Pero qué cambié realmente? ¿Esto tendrá un impacto en mi aplicación? ¿Y cuándo debería uno desmarcar esto? Quiero reutilizar los tipos en los que he configurado DataContract, pero no más. ¿Seguiré teniendo acceso a aquellos sin esta marcada?

Cuando agrega una referencia de servicio, hay dos formas en que se pueden manejar los tipos que utiliza el servicio:

  • Los tipos se almacenan en un dll, y ese dll se referencia desde el cliente y la aplicación del servidor.
  • Los tipos no están en un dll referenciado por el cliente. En ese caso, la herramienta que crea la referencia de servicio creará los tipos en el archivo references.cs.

Hay muchas cosas que pueden salir mal. Hemos encontrado que si la herramienta falla, a veces es más rápido eliminar la referencia del servicio y comenzar de nuevo.

Hemos dejado de usar la referencia de servicio. Para los proyectos donde tenemos control del cliente y el servicio, usamos el método descrito en este screencast .

Encontré mi respuesta aquí: http://www.lukepuplett.com/2010/07/note-to-self-don-let-wcf-svcutil-reuse.html

Para resumir: desactivé Reutilizar tipos en ensambles de referencia desde el menú Avanzado .


No sé si esto importa, pero no estoy usando MVC, sino formularios web.

También tuve este problema hoy. Me llevó un día entero encontrar mi error. Espero eso ayude.

Mi clase que no se pudo importar tiene una propiedad de tipo cutum enum. Esta propiedad está marcada como DataMember y Enum también está marcada como DataContract. Todo bien hasta ahora. Me olvidé de marcar cada miembro enum como EnumMember.

Así que cambié

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

A esto:

 [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 } 

¡Y finalmente funcionó!

eso puede sonar extraño, pero lo solucioné borrando las referencias, cerrando Visual Studio y volviéndolo a abrir, y finalmente agregando las referencias nuevamente.

Creo que la herramienta personalizada necesita reiniciarse o algo así.

Vaya a Propiedades avanzadas al agregar referencia y elimine “System.Window.Browser” de la lista de verificación. Resuelve el problema.

Constantemente encuentro este error mientras funciona en otra máquina de desarrollo. Aunque soy un administrador completo en todas partes en mi máquina virtual, traté de cerrar Visual Studio y volver a abrir con ‘Run As Administrator’ y funcionó mágicamente.

Buena suerte.

Una desventaja de desactivar los “tipos de reutilización en ensambles a los que se hace referencia” es que puede causar problemas con referencias ambiguas. Esto se debe a que la referencia de servicio crea esos objetos nuevamente en el archivo .cs de referencia, y el código que implementa el servicio puede estar haciendo referencia a ellos desde el espacio de nombres original.

Cuando se produce este escenario, me resulta útil verificar los ‘tipos de reutilización en conjuntos de referencia especificados’, lo que me permite elegir los que tienen solo referencias ambiguas, lo que resuelve el problema rápidamente de esa manera.

Espero que ayude a alguien más.

Recibí la advertencia después de actualizar mi solución de Visual Studio (VS) de 2010 a 2013 y cambiar el .NET Framework de cada proyecto de 4 a 4.5.1. Cerré VS y volví a abrir y las advertencias desaparecieron.

Mis interfaces del servicio WCF están en un ensamblado, la implementación está en otra y la referencia de servicio está en otro ensamblaje, separado de los clientes de la referencia de servicio. Recibí el mensaje de error justo después de aplicar el DataContract a una enumeración. Después de aplicar EnumMember a los campos de la enumeración, el problema se resolvió.

Si tiene dudas de que su servicio no tiene ningún problema (como problemas con las enumeraciones o las clases no serializables mencionadas por otros), intente crear un nuevo proyecto con una nueva referencia.

Estoy usando Silverlight 5 y había intentado eliminar y recrear la referencia varias veces. El archivo reference.cs simplemente salió completamente vacío cada vez y habían pasado literalmente años desde que lo había creado, por lo que tratar de descubrir qué había cambiado en el servicio estaba fuera de discusión.

Noté que el error contenía referencias a 2.0.5.0. Ahora ni siquiera sé si esto es realmente relevante para la versión de Silverlight, pero me hizo pensar en crear un nuevo proyecto y de repente todo funcionó.

Advertencia 2 Advertencia sobre herramientas personalizadas: no se puede importar wsdl: portType Detail: se produjo una excepción al ejecutar una extensión de importación WSDL: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Error: No se pudo cargar el archivo o ensamblado ‘System.Xml, Version = 2.0.5.0, Cultura = neutral, PublicKeyToken = 7cec85d7bea7798e ‘o una de sus dependencias. El sistema no puede encontrar el archivo especificado. XPath to Error Fuente: // wsdl: definitions [@targetNamespace = ”] / wsdl: puerto Tipo [@ name = ‘IShoppingCart’]

Estaba revisando mi proyecto y estaba teniendo el mismo problema. Resultó ser versiones diferentes de la misma DLL en WCF vs. Sitio web. El sitio web tenía una versión más nueva de la DLL y el servicio hacía referencia a una versión anterior de la DLL. Una vez que todos estuvieron sincronizados, todo funcionó bien.

Experimenté el mismo error. Luché por casi un día tratando de descubrir qué estaba pasando mal. La pista para mí fueron las advertencias que VS estaba lanzando. Estaba intentando hacer algún tipo de mapeo a Yahoo.Yui.Compressor.dll, una biblioteca que había agregado y eliminado (porque decidí no usarlo) un par de días antes. Fue impactante porque la biblioteca no estaba allí, pero de alguna manera intentaba hacer referencia a ella.

Finalmente, restauro este dll de la Papelera, y luego pude actualizar mi referencia de servicio con éxito.

Para cualquiera aquí en el futuro, tuve el mismo error pero causado por problemas de versión, en dos formas diferentes.

Tengo dos servicios WCF y dos aplicaciones cliente que hablan a través de las referencias de servicio. Actualicé un paquete nuget en ambos lados e intenté actualizar la referencia del servicio y obtuve este error.

Eliminar no ayudó. Desmarcar “ensambles de reutilización” no es deseable ya que necesito reutilizarlos – ese es el punto.

Al final, hubo dos problemas separados:

1) El primer problema, creo, fue un problema visual de caché de estudio. Revisé meticulosamente todas las referencias y no encontré ningún problema, pero aún así informó que no podía encontrar la versión anterior del archivo. Desinstalé todos los paquetes nuget, reinicié Visual Studio y los reinstalé. Actualizando la referencia de servicio trabajada.

2) El segundo problema fue causado por un problema de dependencia. Actualicé el paquete nuget en ambos lados y todo parecía correcto, pero una dependencia no marcada no estaba sincronizada. Ejemplo:

El paquete Foo v1 hace referencia a la barra v1. Es posible actualizar Foo y Bar a v2 de forma independiente sin actualizar la referencia. Si instala tanto Foo como Bar v2, la herramienta de referencia del servicio escaneará Foo v2, verá la referencia a la Barra v1 y fallará porque no puede encontrar la versión anterior. Esto solo se informa correctamente si actualiza los números de versión de su dll para cada paquete. Visual Studio y MSBuild no tendrán problemas para comstackr la aplicación, pero la referencia de servicio tendrá un tiempo terrible para intentar resolverlo todo.

Espero que esto ayude a alguien.