plugin open .net wcf exception-handling wcf-extensions

.net - plugin - open graph facebook



¿Por qué no se encuentra el tipo de elemento de extensión de comportamiento WCF personalizado? (10)

Tengo una solución que contiene dos proyectos. Un proyecto es un Proyecto de Aplicación Web ASP.NET, y uno es una biblioteca de clase. La aplicación web tiene una referencia de proyecto a la biblioteca de clases. Ninguno de estos tiene un nombre fuerte.

En la biblioteca de clases, que llamaré "Framework", tengo un comportamiento de punto final (una implementación de IEndpointBehavior) y un elemento de configuración (una clase derivada de BehaviorExtensionsElement). El elemento de configuración es para poder adjuntar el comportamiento del punto final a un servicio a través de la configuración.

En la aplicación web, tengo un servicio WCF habilitado para AJAX. En web.config, tengo el servicio AJAX configurado para usar mi comportamiento personalizado. La sección system.serviceModel de la configuración es bastante estándar y se ve así:

<system.serviceModel> <behaviors> <endpointBehaviors> <behavior name="MyEndpointBehavior"> <enableWebScript /> <customEndpointBehavior /> </behavior> </endpointBehaviors> </behaviors> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> <services> <service name="WebSite.AjaxService"> <endpoint address="" behaviorConfiguration="MyEndpointBehavior" binding="webHttpBinding" contract="WebSite.AjaxService" /> </service> </services> <extensions> <behaviorExtensions> <add name="customEndpointBehavior" type="Framework.MyBehaviorExtensionsElement, Framework, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> </behaviorExtensions> </extensions> </system.serviceModel>

En tiempo de ejecución, esto funciona perfectamente. El servicio WCF habilitado para AJAX utiliza correctamente mi comportamiento de punto final configurado personalizado.

El problema es cuando trato de agregar un nuevo servicio AJAX WCF. Si hago Agregar -> Nuevo elemento ... y selecciono "Servicio WCF habilitado para AJAX", puedo ver cómo agrega el archivo .svc y el código subyacente, pero cuando se trata de actualizar el archivo web.config, aparece este error:

El archivo de configuración no es un archivo de configuración válido para WCF Service Library.

No se pudo cargar el tipo ''Framework.MyBehaviorExtensionsElement, Framework, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null'' registrado para la extensión ''customEndpointBehavior''.

Obviamente, la configuración es completamente válida, ya que funciona perfectamente en tiempo de ejecución. Si elimino temporalmente el elemento de la configuración de mi comportamiento y luego agrego el Servicio WCF habilitado para AJAX, todo funciona sin problemas.

Desafortunadamente, en un proyecto más grande donde tendremos múltiples servicios con varias configuraciones, eliminar todos los comportamientos personalizados temporalmente será propenso a errores. Aunque me doy cuenta de que podría irme sin utilizar el asistente y hacer todo de forma manual, no todos pueden hacerlo, y sería bueno poder usar el producto tal como estaba destinado a usarse: asistentes y todo.

¿Por qué no se encuentra el tipo de elemento de extensión de comportamiento WCF personalizado?

Actualizaciones / aclaraciones:

  • Funciona en tiempo de ejecución, simplemente no es tiempo de diseño.
  • El ensamblado de Framework está en la carpeta bin del proyecto web cuando intento agregar el servicio.
  • Si bien podría agregar servicios de forma manual ("sin configuración"), necesito que la plantilla de artículos listos para usar funcione, ese es el objetivo general de la pregunta.
  • Este problema se está viendo en Visual Studio 2008. En VS 2010 esto parece estar resuelto.

Archivé este problema en Microsoft Connect y resulta que o bien debe colocar su elemento de configuración personalizada en el GAC o ponerlo en la carpeta IDE. No lo arreglarán, al menos por ahora. He publicado la solución alternativa que proporcionaron como la "respuesta" a esta pregunta.

¿Tiene una copia de Framework.dll con su comportamiento personalizado en el directorio bin de su proyecto web? Si no, ese es probablemente el problema. Visual Studio está buscando la implementación del comportamiento. Dado que está en la lista en su configuración, no se ve en los otros proyectos; espera encontrar el conjunto en el contenedor.

Dependiendo de cómo esté configurado su proyecto, es posible que se ejecute en depuración sin que este ensamble se coloque en el contenedor, aunque VS generalmente lo construye y lo coloca allí. Pero, de nuevo, depende de cómo se configuran las cosas.

De todos modos, tal vez solo quiera verificar que el ensamblaje esté disponible en el momento del diseño.

Acabo de usar

[assembly: AssemblyVersion("1.0.*")] //[assembly: AssemblyVersion("1.0.0.0")] //[assembly: AssemblyFileVersion("1.0.0.0")]

Así que tengo un nuevo número de compilación de ensambles todo el tiempo.

Pero tenemos

<add name="clientCredential" type="Client.ClientCredentialElement, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

donde Versión = 1.0.0.0 ¡ ESTO ES INCORRECTO!

Entonces tienes 2 opciones

  1. De regreso

    //[assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.0.0")] Keep it manually. [assembly: AssemblyFileVersion("1.0.0.0")]

  2. Cada build reemplaza manualmente Version = 1.0.0.0 con un número correcto.

Aquí está la lista de pasos trabajados para mí:

  • Instalar dll en GAC, es decir, gacutil / i Bla.dll
  • Obtener FQN de dll, es decir, gacutil / l Bla
  • Copie el FQN resultante en Web.config
  • Agregar nuevo servicio en VS
  • Desinstalar dll de GAC, es decir, gacutil / u Bla

Todos juntos solo .

Colocar la asamblea en el GAC probablemente sea útil, pero agradezco que esta no sea la respuesta que está buscando. No estoy seguro de dónde más buscará VS ensamblajes aparte del GAC y el directorio que contiene devenv.exe.

Como un FYI para cualquiera que tropiece con esto en estos días, una posible solución es COMPLETAMENTE calificar su ensamblaje en su app.config / web.config. Por ejemplo, si tuvieras

<system.serviceModel> <extensions> <behaviorExtensions> <add name="clientCredential" type="Client.ClientCredentialElement, Client" /> </behaviorExtensions> </extensions>

intentar - reemplazar los valores como necassary

<system.serviceModel> <extensions> <behaviorExtensions> <add name="clientCredential" type="Client.ClientCredentialElement, Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> </behaviorExtensions> </extensions>

esta solución particular funcionó para mí.

Intenté esto con un nuevo proyecto solo para asegurarme de que no era su proyecto / configuración específico y tenía exactamente el mismo problema.

Utilizando registros de fusión, parece que el sistema busca SOLAMENTE las extensiones de comportamiento en el directorio IDE (C: / Archivos de programa / Microsoft Visual Studio 9.0 / Common7 / IDE). Copiar el conjunto a este directorio en un paso posterior a la compilación funciona, pero es feo.

Lo resolví comentando las secciones relevantes en web.config, incluido el elemento que usó la extensión personalizada, el elemento y el elemento.

Después de eso, pude agregar un servicio WCF al proyecto, agregar las líneas nuevamente en el web.config y publicar el proyecto.

Según la solución alternativa que Microsoft publicó en el problema de Connect que presenté para esto, es un problema conocido y no habrá ninguna solución para él, al menos en la versión actual:

El motivo de no agregar un nuevo elemento de servicio: al agregar un nuevo elemento y actualizar el archivo de configuración, el sistema intentará cargar el archivo de configuración, por lo que intentará buscar y cargar el ensamblaje de la extensión de la computadora en este archivo de configuración. Solo en los casos en que el ensamblado tiene GAC o está ubicado en la misma ruta que vs exe (Archivos de programa / Microsoft Visual Studio 9.0 / Common7 / IDE), el sistema puede encontrarlo. De lo contrario, el cuadro de diálogo de error aparecerá y "agregar un nuevo elemento" fallará.

Entiendo tus puntos dolorosos Desafortunadamente no podemos tomar este cambio en la versión actual. Lo investigaremos en lanzamientos posteriores y trataremos de proporcionar una mejor solución en ese momento, como proporcionar un diálogo de exploración para permitir a los clientes especificar la ruta, o un mejor mensaje de error para indicar alguna solución alternativa, etc.

¿Puedes probar el trabajo en la etapa actual: GAC tu ensamblado de extensión personalizado o copiarlo a "Archivos de programa / Microsoft Visual Studio 9.0 / Common7 / IDE"?

Proporcionaremos el archivo Léame para ayudar a otros clientes que puedan tener el mismo problema.

Desafortunadamente, parece que no tengo suerte en este caso.

Tenía la clase de extensión dentro del mismo proyecto (dll) que mi clase de servicio y no pude hacer que funcionara. Una vez que lo moví a otro proyecto y lo hice referencia desde el proyecto de servicio, funcionó. Solo en caso de que alguien más se encuentre con este problema.

si está utilizando el marco 3.5, Culture = neutral en small no Culture = Neutral en CAPITAL