[WPF] Library project file cannot specify ApplicationDefinition element

Imagina la siguiente situación: Tienes un proyecto en WPF, con varias ventanas o controles WPF creados, y de repente te da por reorganizarlo todo un poco. Así, que añades un proyecto de tipo "Class Library" a la solución, y luego arrastras desde el Solution Explorer, algunas de las ventanas y/o controles al nuevo proyecto.
Cuando más o menos lo tienes todo, le das a compilar y Visual Studio se queja con dos errores:

• error MC1002: Library project file cannot specify ApplicationDefinition element.
• error BG1003: The project file contains a property value that is not valid.

Además aunque le des doble-click en la ventana de errores, Visual Studio no está dispuesto a decirte en que línea o al menos que fichero es el causante de los dos errores.
El error se produce cuando al arrastrar los controles xaml al nuevo proyecto, Visual Studio cambia la "Build Action" de los controles que hayas arrastrado de "Page" a "ApplicationDefinition", y una librería no puede tener ningún control o ventana xaml con "ApplicationDefinition". Así pues, seleccionas en el "Solution Explorer" los ficheros xaml que hayas arrastrado (si arrastras más de un archivo te los cambia todos) y en propiedades, pones "Build Action" a "Page"... y listos!
Saludos!
PD: El fichero que tiene la Build Action como "ApplicationDefinition" es aquel que proporciona el punto de entrada de la aplicación y por lo tanto solo es válido en ejecutables (suele ser el App.xaml).
Crosspost desde mi blog de geeks.ms.

[Catdotnet] Ya pasó El Guille por Igualada :)

Bueno... ya pasó El Guille por Igualada, en la sexta etapa de la Guille Community Tour.

La verdad es que para un grupo de usuarios como CatDotNet fue un honor que un ponente de su categoría, se acercara a hacernos una visita, y deleitarnos a todos con su magnífica presentación sobre las novedades que trae Visual Basic 2008 (o VB9), amenizada con numerosas bromas y simpáticos ejemplos. Nos contó la anécdota de "MiAmiguito" con el fondo rosa que menciona Jose Luis Latorre, pero nuestro proyector funcionaba bien, así que no pudimos verla, jejejeee... :P

Como no podía ser menos batimos todos los récords de asistencia, con unas 35 personas más o menos, y El Guille demostró porque es uno de los mejores ponentes de toda España.

En fin, fue una magnífica presentación (como no podía ser menos)... solo aprovechar para decir que si hay alguien de Igualada o cerquita, o simplemente interesado en saber qué movidas vamos organizando, que se ponga en contacto conmigo o con Jose Luis Torres y vamos hablando!!!!!

Nos vemos!!!!

PD: Uuuuups.... no tengo las fotos a mano ahora, pero tan buen punto las tenga, colgaré algunas para que podais verlas ;-)

(Crossposting desde geeks.ms)

[Catdotnet] El Gulle en Igualada

Hola a todos!

Sólo una reseña, para comentaros que "El guille", uno de los MVPs más antiguos y autor de uno de los portales más visitados de desarrollo en .net, se pasará este jueves 09 de octubre para Igualada, en el marco de su gira "Guille Community Tour 2008".

No hay que decir que se trata de una oportunidad única para poder ver a uno de los mejores ponentes de la actualidad, quien nos presentará todas las novedades de la última versión de Visual Basic...

¿Te lo vas perder?

Cuando: Este jueves (09/10/2008) a las 19:00

Donde: Centre d'atenció a les empreses (Av Mestre Muntaner 86 - Igualada)

Para registrarse:  http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032389560&Culture=es-ES

[WCF] Hospedando servicios

Bueno... en esta serie de posts sobre esta excitante tecnología que es WCF, hemos visto como crear un servicio, y como configurar un servicio usando el fichero de configuración.
Pero un servicio por si sólo no es nada: estaría bien que tuviese al menos un cliente (porqué si no es posible que se sienta un poco inútil). Vale, vale... aceptamos pulpo como animal de compañía, un servicio puede vivir sin ningún cliente pero lo que no me podeis negar es que lo que sí que necesita forzosamente es un servidor que lo acoja en su seno proceso.
Sí: los servicios en esto son como los virus: si no hay alguien que los hospede, son totalmente inútiles :)


Vale, tenemos claro que necesitamos hospedar nuestro flamante servicio pero... donde? Necesitamos comprar un "servidor de servicios" ? Podemos usar IIS? No lleva VS ningún servidor de piltrafilla que nos sirva en desarrollo? Pues (como ya viene siendo habitual en el mundo Microsoft) hay muchas maneras de enfocar la historia...


En general, el proceso que hospeda un servicio WCF es, básicamente, el CLR. Esto viene a significar que cualquier proceso .NET puede hospedar un servicio. Sí, sí: he dicho cualquier proceso. Una aplicación winforms? Pues sí. Una aplicación de línea de comandos? Pues también. Y claro está IIS también es una opción disponible, al igual que un servicio windows. Entonces? Bueno, decidir como hospedamos nuestros servicios es una decisión que se toma basándose en los requerimientos y en la arquitectura global de la solución. Cada sistema tiene sus ventajas y sus inconvenientes.
Por ejemplo, si usamos un ejecutable (sea winforms o linea de comandos), evidentemente el dicho ejecutable debe estar en marcha para que nuestros servicios esten disponibles. Esto invalida entornos desasistidos donde no habrá nadie para "poner en marcha" nuestro host, en estos entornos será mucho mejor un servicio windows. Por otro lado los hosts que son ejecutables estándar, son muy fáciles de crear y de depurar. De hecho no es extraño que durante el desarrollo, se use un servidor que sea un ejecutable, para migrar a un servidor "real" en una fase final.


Y... IIS? Hombre, pues claro. IIS puede hospedar servicios. Además, seguramente, es el mejor hosting posible, ya que si IIS sabe hacer algo és hospedar cosas y servirlas a sus clientes. Y que ventajas nos aporta IIS? Pues varias y muy importantes, entre las que destacaríamos temas de monitorizacion, activación del servicio on-demand y reciclaje de procesos. Estos temas deben "codificarse" a mano si uno opta por un host propio, mientras que en IIS nos vienen de serie. Además IIS es eficiente y altamente escalable... que razón para no usarlo? Lamentablemente podría haber una... Que pasa si mi transporte NO es http ó https? Sabe gestionar otros protocolos de transporte nuestro querido IIS? La respuesta, como todo es... depende.


Tienes XP y tienes un servicio que no usa http(s) como transporte? Pues lo siento, pero NO puedes usar IIS como hosting: En XP y 2003 IIS sólo soporta servicios con transporte http(s). Por otro lado si tienes Vista o 2008 entonces... entonces estás de suerte: WAS viene en tu ayuda!


Estoooo... WAS? Que narices es WAS? No hablábamos de IIS? WAS es el acrónimo de "Windows Activation Services", que es un nuevo sistema de activación de procesos, disponible sólo de Vista para adelante. IIS7 usa internamente WAS, para cualquier tipo de servicio (sea http(s) o no). Pero IIS7 no es un requisito de WAS, es decir podemos tener WAS sin IIS7 y hospedar cualquier tipo de servicio y no usar IIS7 a menos que lo necesitemos para otras cosas (p.ej. ASP.NET). Y no os preocupeis por las ventajas que nos ofrecía IIS7 (reciclaje de procesos, activación on-demand, etc): WAS también las ofrece (recuerdo: IIS7 usa WAS internamente).


Así, tendriamos las siguientes opciones:

• Ejecutable (winforms o consola): Sencillo, fácil y útil en etapas de desarrollo. No apto en producción.
• Servicio Windows: Única opción para hospedar servicios que no usen http(s) en XP y 2003.
  
• IIS 5.1 ó 6 en XP y 2003: Ideal para todos los servicios que usen http(s). Ganamos todas las ventajas que nos ofrece IIS.
• WAS: Ideal para cualquier servicio, pero requiere Vista, 2008 o posterior. Ganamos todas "las ventajas de IIS"... sin necsidad de tener IIS.
  
• IIS7 en Vista o 2008: Ideal para cualquier tipo de servicio. Tenemos todas las ventajas de IIS y además permite interoperar nuestros servicios WCF con ASP.NET.
  

Una vez visto el abanico de opciones disponibles para hospedar nuestros servicios, vamos a ver un ejemplo de como hospedar un servicio WCF, usando la aplicación más simple posible: una aplicación de linea de comandos.


Para hospedar un servicio se usa la classe ServiceHost. El constructor de esta clase espera un parámetro que es un objeto Type con la información de la clase que implementa el servicio. Por ejemplo, si tengo la clase CalculadoraService que me implementa un servicio, para ponerlo en marcha, debo construir un ServiceHost y abrir el canal de comunicaciones:

ServiceHost shCalc = new ServiceHost(typeof(CalculadoraService));

shCalc.Open();

// ....

shCalc.Close();

 
Y listos! Esto es todo! Esta es la manera más simple de poner en marcha un servicio. El servicio utilizará los endpoints que haya definido en el fichero de configuración de la aplicación host.
Evidentemente con la clase ServiceHost podemos personalizar más el proceso de hosting, por ejemplo podemos configurar endpoints programáticamente (en lugar de usar el fichero deconfiguración).

Bueno.... ya sólo nos queda ver una cosilla para cerrar el círculo de esa introducción de WCF: Sí, sí... el cliente!


Saludos!

Catdotnet - Este viernes... de lujo!

Pues sí!
Este viernes, en catdotnet nos vestimos de gala! La razón?


Muy fácil, tendremos una sesión de un autentico crack: Miguel Llopis, flamante vencedor de la última ImagineCup, estará en Igualada, para poner un poco de luz en todo lo que significa y es Oslo y el paradigma de SaaS.


Además, para redondear el dia, Jordi Bonilla, nos ofrecerá una interesante charla sobre  software y servicios, los paradigmas SaaS y S+S... en fin, el complemento ideal a la charla de Miguel.


Donde?
En el Centre de Serveis a les empreses en Igualada (Av Mestre Muntaner 86).


Cuando?

Este viernes 05/09/2008 a las 19:00


No falteis!! Os esperaaaaaaaaaaaaaaaaaaamos!!


Editado el 15/09/2008: En la página de catdotnet, teneis la presentación de Miguel Llopis para que os la descargueis!

Y me voy a geeks!

Buenas :)
Este post es para deciros que  abro un blog en geeks.ms, una de las comunidades de blogs tecnológicos más importantes sobre tecnologías Microsoft en castellano.

Es la muerte de este blog? No pues haré crossposting de uno a otro (manualmente, porque no se como hacerlo automáticamente... si alguien lo sabe que me lo diga). Así que este blog sigue vivo, pero si quieres pasate también por mi blog en geeks.ms 

Un saludo!

[WCF] Configurando mis servicios

Bueno.... justo empieza agosto, vacaciones y demás, y antes de que decaiga toda la actividad mundial, aprovecho para contaros algo más de WCF... :) La configuración de los servicios.

En el post anterior vimos como crear un servicio sencillito (ya lo iremos complicando). Lo que hicimos básicamente fueron dos cosas:

• Definir el contrato del servicio (una interfaz de .NET decorada con ServiceContract).
• Implementar el contrato (una clase de .NET que implementaba la interfaz)

Luego vimos que ejecutando el proyecto, Visual Studio nos hospedaba nuestro servicio en un servidor de pruebas y nos permitia probarlo con un cliente de pruebas.

Pero recordais los primeros posts de esta serie? Los endpoints??? Sí, sí...el ABC de WCF: Address, Binding, Contract... dónde está mi servicio, cómo accedo a él y qué hace el servicio.
Pues bien, una de las claves de WCF es que el endpoint se define mediante un fichero de configuración (puede hacerse programáticamente, pero esto ahora no nos interesa).

Es decir, tanto la URI de mi servicio, como el protocolo que usaremos para acceder a él, se define mediante el fichero de configuración... Hoy quieres acceder a tu servicio en http://servidor/servicio1 mediante SOAP en HTTP? Pues lo configuras en el fichero de configuración. Mañana cambias de idea y quieres acceder a tu servicio mediante MSMQ? Pues ningún problema: edita el fichero de configuración. Y listos. No toques ni una línea de código.
Es por esto que decimos que WCF unifica todas las APIs de comunicaciones existentes hasta el momento.

El fichero de configuración de WCF es el estándard de .NET (que VS llama app.config), y toda la configuración de WCF se lleva a cabo en la etiqueta <system.serviceModel>.
Veamos un ejemplo de como puede ser la configuración de UN servicio:


      <service name="ServiciosCalculo.CalculadoraService" behaviorConfiguration="ServiciosCalculo.Service1Behavior">
        <host>
          <baseAddresses>
            <add baseAddress = "http://localhost:8731/Design_Time_Addresses/ServiciosCalculo/Service1/" />
          </baseAddresses>
        </host>
        <endpoint address ="" binding="wsHttpBinding" contract="ServiciosCalculo.ICalculadora">
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
      </service>


Por un lado dentro de la etieuta "service" tenemos dos etiquetas principales:

• host: Que nos permite establecer la dirección (URI) base de este servicio
• endpoint: Que nos define UN endpoint. Recordad que un servicio puede tener MAS de un endpoint

Dentro del endpoint se definen los tres aspectos principales:

1. La dirección. Atributo address que contiene una URI relativa a la dirección base establecida en la etiqueta "host".
2. El binding. Atributo binding que contiene el nombre identificativo del binding que vamos a usar.
   
3. El contrato. Atributo contract que contiene el nombre de la interfaz de .NET que representa este contrato.

En el código de ejemplo vemos que el servicio implementa dos endpoints:

1. Uno con dirección relativa vacía (o sea que la URI de este endpoint es la misma que la definida en la etiqueta host), con el contrato ServiciosCalculo.ICalculadora (la interfaz que hicimos en el post anterior)
2. Otro con dirección relativa "mex", con el contrato IMetadataExchange.

El contrato IMetadataExchange es un contrato que implementan todos los servicios de WCF, y que sirve para que el servicio pueda informar al cliente de sus metadatos (p. ej. los datos del binding o del contrato, para que el cliente sepa a que atenerse... vendría a ser como "la oficina de información" del servicio).

Si os fijais en el trozo de ejemplo que he puesto, en los dos endpoints los dos bindings que hay son:

• wsHttpBinding para el primer endpoint
• mexHttpBinding para el segundo endpoint

Si os preguntais donde definimos la codificación (binaria, SOAP,...) o el transporte (TCP, MSMQ, HTTP) de estos bindings, aquí no lo vais a encontrar ya que estos bindings son bindings predefinidos de WCF.
En este post de Maor David podeis encontrar una comparación de los bindings predefinidos de WCF.
Pero no estamos limitados a estos bindings: un binding es configurable (podemos añadirle o quitarle "elementos") o bien nos podemos crear nuestros propios bindings... pero bueno, esto ya es harina de otro costal. La verdad es que con los bindings predefinidos cubrimos un amplio espectro de necesidades.


Por último los más observadores habreis visto que la etiqueta "service" del ejemplo, definia un atributo llamado "behaviorConfiguration" (con valor "ServiciosCalculo.Service1Behavior"). Esto sirve para indicar el behavior del servicio... y claro que es un behavior?
Pues bien, básicamente son datos de configuración del servicio, que NO forman parte de su endpoint. Por ejemplo: si el servicio da una excepción, queremos enviar información detallada al cliente o no? Los behaviors que tengamos se definen con la etiqueta behavior (dentro de serviceBehaviors) y se asocian a los servicios con el atributo que hemos comentado.
Por, ejemplo un behavior puede se puede definir así:
       <serviceBehaviors>
        <behavior name="ServiciosCalculo.Service1Behavior">
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="False" />
        </behavior>
      </serviceBehaviors>


En posts sucesivos veremos más información sobre los behaviors.
Bien!!!! En el próximo post de la serie veremos como... crear un cliente y conectarnos a nuestros servicios!!!!

Buenas vacaciones a todos los afortunados que las hagais!!
Nos leemos! ;-)