Visual Studio y el misterio de las plantillas desaparecidas

Hoy al arrancar Visual Studio (2010) me he encontrado con la siguiente sorpresa (muy desagradable, por cierto) al ir a generar un nuevo proyecto:

¿Dónde están mis plantillas de proyecto? Sudores fríos por la espalda… menudo comienzo de día ¡Socorro!

Al turrón

Tras el primer momento de pánico, he recordado que Visual Studio proporciona una serie de parámetros de ejecución del IDE (devenv.exe) que permiten por ejemplo resetear las personalizaciones realizadas al Visual Studio, regenerar paquetes instalados, etc.
Investigando un poquillo, he encontrado lo que necesitaba:

1. Cerramos Visual Studio.
2. Iniciamos el “Visual Studio Command Prompt (2010)” (Como Administrador en Windows Vista / 7)
3. Ejecutamos devenv.exe /installvstemplates.
4. Esperamos a que termine (para asegurarnos, lo mejor es abrir el Task Manager y esperar a que el proceso “devenv.exe *32” desaparezca.
5. Arrancamos Visual Studio, y

Ya está!!! Sencillo ¿verdad? ahora lo único que queda pendiente es averiguar por qué de buenas a primeras habían desaparecido prácticamente todas las pantallas de proyectos (tengo un par de componentes sospechosos, pero si llego a alguna conclusión la haré pública.

NOTA: Este comando se puede ejecutar mínimo desde la versión de Visual Studio 2005.

Probar aplicaciones en un dispositivo iOS

O como comenzar a programar sin pasar por el AppStore

¿Cuál es el problema?

Este artículo tiene la intención única de explicar una posibilidad “desconocida” al menos para mí relacionada con el desarrollo de aplicaciones para dispositivos iOS. Lo vi en varios sitios que no voy a indicar aquí por si acaso.

Las versiones utilizadas en esos artículos eran las siguientes:

Mac OS X 10.6.6

Xcode 3.2.5

 

En principio, cuando desarrollamos una aplicación para dispositivos iOS, la única opción “gratuita” que tenemos es probar dicha aplicación en el simulador integrado en el sistema. Esto es más que suficiente en la mayoría de los casos, pero existen situaciones en las que se queda un poco corto (por ejemplo, interactuar con el GPS)

En condiciones normales, cuando comenzamos el desarrollo de este tipo de aplicaciones, tenemos que ‘comprar’ una licencia a Apple, que nos puede dar derecho tanto a publicar nuestra aplicación en el AppStore como a configurar hasta 100 (me suena que eran 100) dispositivos ‘autorizados’ para realizar pruebas. ¿Qué sucede si no tenemos esa licencia?

La licencia es una suscripción anual y puede ser que únicamente queramos realizar pruebas antes de comenzar el desarrollo ‘en serio’, pero necesitando poder probar ‘en vivo’ las aplicaciones.

¡OJO! Reconozco que no tengo ni idea de si este procedimiento es legal o no, cada cual que haga lo que quiera, yo sólo he visto que existe esta posibilidad y quería recogerla en el lenguaje de Cervantes. Si alguien me advierte de que esto es ilegal, lo elimino y aquí paz y después gloria, que aquí estamos para aprender!

Proceso

Lo primero que se indica es que el dispositivo que queremos utilizar para realizar pruebas tiene que tener hecho el proceso de Jailbreak. Esto ya puede suponer un problema, ya que en función de la versión de iOS del dispositivo, es posible que no se pueda hacer jailbreak. Además del Jailbreak, es dispositivo por lo visto necesita tener instalada la aplicación “AppSync”

Una vez que cumplimos con esos requisitos, arrancamos nuestro MAC

Al turrón

Mediante el “Acceso a Llaveros” generamos un nuevo certificado:

1. Acceso a Llaveros
2. Asistente para certificados
3. Crear un certificado
4. El certificado a crear tiene que ser de tipo “Raíz autofirmada”.

Una vez generado el certificado, tenemos que realizar una modificación a un archivo de configuración de Xcode:

1. Finder
2. Developer
3. Platforms

Una vez en la carpeta “Platforms” elegimos con qué plataforma de las disponibles queremos trabajar (por ejemplo “iPhoneOS.platform”

¡OJO! En los artículos que he visto no mencionaban si alguna de las plataformas es incompatible con este método, supongo que si no funciona habrá que googlear un poco.

Editamos el archivo “Info.plist” (abridlo mejor con “TextEdit” y, lógicamente, guardad antes una copia del archivo)

Localizamos una de las secciones <dict>, concretamente la que comienza con la línea:

<key>ARCHS</key>

A continuación de las líneas:

<key>PLIST_FILE_OUTPUT_FORMAT</key>

<string>binary</string>

Introducimos las siguientes líneas:

<key>PROVISIONING_PROFILE_ALLOWED</key>

<string>NO</string>

<key>PROVISIONING_PROFILE_REQUIRED</key>

<string>NO</string>

A continuación, ejecutamos Xcode y abrimos el proyecto que queremos depurar.

¡OJO! Estos pasos hay que repetirlos en todos los proyectos que queramos depurar en un dispositivo físico, recordad que por regla general es suficiente con el simulador integrado.

1. Menú Project
2. Edit Project Settings
3. Pestaña Build
4. Sección Code Signing

En las propiedades “Code Signing Identity” y “Any iOS” establecemos el certificado local que creamos en su momento para montar todo este tinglado.

Y para acabar, en el desplegable del proyecto, elegimos el dispositivo en lugar del simulador y a jugar!!!

Consideraciones finales

Otra vez quiero indicar que desconozco si esta práctica es 100% legal, en principio realizar un Jailbreak a un dispositivo iOS es legal, aunque se pierde la garantía del aparato. El resto de pasos son cambios a archivos de configuración, con lo que entiendo que no debería suponer ningún problema.

Seguiré vigilando el tema y en el momento en el que tenga sospechas de la legalidad del mismo, actualizaré el artículo en consecuencia.

Ahora sí, para terminar, una ‘pequeña’ justificación, no he podido / querido utilizar capturas de pantalla, ya que yo no he probado el procedimiento y tampoco quería utilizar capturas de terceros.

Generar builds en TFS para proyectos de Sharepoint

O cómo compilarlos automáticamente sin morir en el intento.

Los últimos días he retomado el desarrollo de componentes para Sharepoint, que tenía bastante “oxidado” y como no podía ser de otra manera, he integrado el proceso de desarrollo dentro del TFS 2010. La situación que tenía (para tener claro de qué estoy hablando) era la siguiente:

• Equipo de desarrollo: Windows 2008 R2 de 64 Bits.
• Sharepoint Server 2010 instalado en el equipo de desarrollo.
• Visual Studio 2010.
• Servidor de fuentes: Team Foundation Server 2010.

 

Pasos Previos

Lógicamente antes de nada, hay que realizar las operaciones clásicas cuando utilizamos TFS (creación del Team Project, rama Main, etc.)

Hasta aquí nada nuevo bajo el sol, estuve realizando el componente (en este caso una WebPart) y llegó la hora de probarlo en el entorno de Preproducción.

Para la instalación en ese entorno, únicamente utilicé el WSP que genera Visual Studio al ‘empaquetar’ el proyecto de Sharepoint, pero se me ocurrió que tenía que ser posible utilizar las Builds de TFS para que ese paquete WSP se genere automáticamente, como el resto de productos alojados en TFS.

La verdad es que no resultó tan sencillo como yo esperaba, aunque los problemas y pasos para solucionarlos tienen mucho sentido.

Primer intento

Lo primero que intenté fue lo típico, generé una nueva Build Definition, y la ejecuté… Resultado:

Como vemos, al realizar la compilación el agente detecta que en el proyecto hay referencias que no le gustan, o que no conoce, vamos, que no existen en el servidor…

Esto es normal, ya que ni Visual Studio ni, por supuesto, Sharepoint están instalados en el servidor de compilación.

Segundo intento

Como no funcionó, tocó “googlear” un rato, y lo primero que encontré fue un “apunte” en el que indicaba que con una Build Definition ”normal” no se conseguía generar el WSP para el componente. Para solucionar ese problema, es suficiente con añadir el parámetro “/p:IsPackaging=True” en la sección de “MSBuild Arguments” de la Build Definition:

Pero aún hay más, encontré una pequeña ‘maravilla’ que en principio simplifica el proceso. Dicha maravilla es un script de Powershell que en un primer paso permite coger los ensamblados de Sharepoint de la máquina de desarrollo, y en una segunda pasada los copia y registra en el servidor de compilación. No voy aquí a repetir los pasos de ejecución de dicho script, ya que está suficientemente explicado aquí, pero baste una captura para ver el resultado de la compilación una vez ejecutado el script tanto en la máquina de desarrollo como en el servidor de compilación:

Bueno, tampoco íbamos a esperar que funcionase a la primera no?

Lo que ha pasado es que el script que hemos ejecutado sólo coge los ensamblados básicos de Sharepoint:

"Microsoft.SharePoint.dll"
"Microsoft.SharePoint.Security.dll"
"Microsoft.SharePoint.WorkflowActions.dll"

Como nuestro proyecto es una Web Part que hereda de un tipo de "Microsoft.Office.Server.Search.dll", tendremos que añadir dicho ensamblado en la sección “$Script:SharePoint14ReferenceAssemblies” del script que hemos ejecutado.

NOTA: Al ejecutar el nuevo script en la máquina de desarrollo es posible que nos dé un error de que ese ensamblado no se puede localizar, si es el caso, basta con copiarlo desde la carpeta ISAPI de Sharepoint a la carpeta “Files” que se genera al ejecutar el script (si no sabes dónde está la carpeta ISAPI, creo que te has equivocado de post)

Al final, después de pruebas y error, llegamos al…

Tercer intento

En el script mágico tuve que añadir los siguientes ensamblados en la sección que indicaba antes:

"Microsoft.Office.Server.dll"
"Microsoft.Office.Server.Search.dll"
"System.Web.DataVisualization.dll"

Tras ejecutarlo en el servidor de compilación, lanzamos la Build y:

¡Por fin! ya tenemos compilaciones automáticas desde TFS 2010 de proyectos para Sharepoint; además, podemos observar en la carpeta de los Drops que la compilación ha generado el paquete WSP:

Nota final

Como podemos ver en la última captura, la Build no sólo genera el paquete WSP, sino que también está llevando a la carpeta de Drops los ensamblados que hemos añadido durante el proceso. He investigado un poquillo y parece ser que se podrían eliminar de dicha carpeta en uno de los pasos del Workflow de la Build Definition, pero reconozco que no he ahondado más en el tema. Si por lo que sea llegamos a tener problemas de espacio, podemos borrar todos esos ensamblados de las distintas compilaciones. Oye, aunque tengamos que borrarlos a mano, sigue siendo mejor que lo que teníamos antes no?

Análisis de código

Integrada con Visual Studio disponemos de una herramienta de análisis de código, que se encarga de comprobar que el código existente en el proyecto cumple unas ciertas normas (o reglas) de calidad.

Dicha herramienta se configura desde la ventana de propiedades del proyecto, en la pestaña “Code Analysis”

 

Como podemos observar en la captura anterior, podemos configurar el análisis de código para que se ejecute automáticamente al compilar el proyecto y más importante, podemos definir el conjunto de reglas de análisis que queremos que se comprueben contra el código. Este conjunto de reglas está predefinido, y las reglas en sí están agrupadas por categorías. Las categorías disponibles aparecen en la siguiente captura, en la que podemos ver también que dichas categorías pueden excluirse del análisis de código como una unidad completa.

Para ver las reglas que se aplican en cada categoría, basta con desplegar el árbol correspondiente, y aparecen todas las reglas de la categoría, con un nombre “descriptivo” del sentido de la regla así como una casilla de verificación que nos permite excluir una regla concreta del análisis en lugar de toda la categoría:

¿Cómo ejecutamos el análisis de código?

Una vez que hemos seleccionado el conjunto de reglas que queremos aplicar al análisis, es hora de ejecutarlo… Pero ¿cómo lo hacemos?

Fácil fácil, venga que sí de verdad:

1. Clic con el botón derecho del ratón sobre el proyecto.
2. Clic en “Run Code Analysis”

¿Difícil?

¿Cómo vemos los resultados?

Ésta es una pregunta trampa, ya que como veremos cuando ejecutemos el análisis de código, Visual Studio utilizará la ventana de “Error List” para mostrar todas las incidencias que haya encontrado… Preparaos para un buen SUSTO!!

Última consideración

En la última captura podemos ver que las reglas que no se están cumpliendo aparecen como “Warnings” en la ventana, esto es configurable desde la ventana de detalle de las categorías y reglas:

Si cambiamos la configuración, el estado de las reglas incumplidas también cambiará pasando a ser error o a desaparecer.

Fin de la historia… ¿Fin? no exactamente, en breve tendré otro artículo para explicar cómo podemos añadir nuestras reglas personalizadas al Análisis de Código.

Controles personalizados, databinding y tabs

Apunte rápido, truco aún más rápido, para que no se me olvide.

Situación

Tenemos un control personalizado al que le asignamos el valor mediante databinding, hasta aquí todo normal.

Metemos el control personalizado en la primera pestaña del control de pestañas de .Net y hasta aquí, todo normal.

Metemos el control en otra pestaña (que no sea la primera, como podemos imaginar) y cuando accedemos a la pestaña en cuestión, el control NO tiene el valor asignado mediante el databinding.

Al turrón

No voy a entrar en mucho detalle, ya que la “solución” adoptada ha sido bastante sencilla, queda pendiente una investigación más ‘a fondo’ para ver si realmente el problema está en al gestión de la información que hace el control Tab (y todos los que hereden de él) o el problema está en el diseño del control personalizado.

No me hago de rogar, la solución ha sido “refrescar” el “BindingContext” del control personalizado.

El trozo de código que he implementado sería:

myCheckListBox.BindingContext = this.BindingContext;

En el caso concreto que me ocupaba, el databinding se realizaba sobre un control incluido dentro del control personalizado, con lo que en la rutina de carga, ha sido suficiente añadir:

this.ListaValores.BindingContext = this.BindingContext;

Fin de la historia.

Cómo activar una aplicación heredada con Lync 2010

O cómo pasar una aplicación integrada con OCS 2007 a LYNC 2010 sin morir en el intento

 

Situación inicial

Partimos de una aplicación desarrollada con el UCMA 2.0 de OCS que, básicamente registra un nuevo usuario o SIP en el servicio de OCS y permite establecer conversaciones con él, lo que viene a ser un BOT de toda la vida.

En este artículo no vamos a ver código como tal, ya que la aplicación original no sufre ningún cambio a la hora de ‘migrarla’ a un entorno de LYNC 2010. Como ya podemos imaginarnos, lo más correcto hubiera sido migrar la propia aplicación al UCMA 3.0, pero en esta ocasión no disponemos del tiempo necesario, así que ¿Qué hacemos?

Como explicación inicial, indicar que la aplicación que queremos ‘reconfigurar’ está funcionando correctamente en un entorno OCS 2007, y su configuración inicial se realizó con la herramienta “Application Provisioner” (enlace)

 

Primer intento

Nuestra aplicación está correctamente aprovisionada en el OCS, y dado que nuestra infraestructura lo permite, la primera intención es simplemente modificar el archivo de configuración para apuntar al nuevo servidor de LYNC en lugar de al servidor original. Resultado, no funciona; el endpoint establece correctamente la conexión, la cuenta en el cliente LYNC aparece como disponible, pero al iniciar una conversación, se produce un error.

Revisando el visor de eventos, encontramos el siguiente error:

 

Segundo intento

A continuación intentamos modificar el host de LYNC (“OCS Pool Fqdn”) mediante la herramienta “Application Provisioner”. Resultado, no se puede, hay que generar un Application Pool nuevo. De acuerdo, si no queda más remedio, creamos uno nuevo, con las mismas características que el anterior, pero utilizando el nuevo Host de LYNC.

Ojo, porque si queremos mantener el servidor de aplicaciones, tendremos que eliminar el Application Pool anterior, ya que de lo contrario nos encontraremos con es siguiente error:

Una vez creado el nuevo pool, actualizamos en el archivo de configuración de la aplicación el “GRUU” y lanzamos la prueba. Resultado, no funciona; el cliente LYNC vuelve a mostrar el mismo error de antes, y en el visor de eventos, de nuevo el mismo error.

 

Replanteamiento

Si no puedes con el enemigo, únete a él. En este momento, tenemos una aplicación que no funciona en ningún entorno, así que hacemos marcha atrás, y volvemos a la situación inicial.

Entonces, ¿qué hacemos? tras mucho mirar y remirar por ahí, acabamos llegando a la conclusión (por otra parte lógica) de que el mecanismo de aprovisionamiento para OCS NO es compatible con LYNC y que la única manera de realizar la “reconfiguración” va a ser pelearnos con Powershell en el servidor LYNC.

 

Al turrón

Con la aplicación aprovisionada en el servidor OCS 2007, tenemos que ejecutar unos comandos de Powershell en el servidor LYNC, para lo que iniciamos la consola de administración de LYNC (“Lync Server Management Shell”) que no deja de ser una consola de Powershell (recomendado hacerlo como Administrador) y empezamos a ‘picar’ instrucciones:

1. “Merge-CsLegacyTopology -TopologyXmlFileName newtopology.xml”
2. “Publish-CsTopology -FileName newtopology.xml”
3. “Enable-CsTopology”
   Estas instrucciones recrean el pool original de OCS 2007 en la topología del servidor LYNC.
4. “Move-CsApplicationEndpoint {identity] -TargetApplicationPool {fqdn} –Force”
   Esta instrucción mueve los contactos al nuevo pool, con lo que en principio ya estaríamos listos.

¿Cómo averiguamos el “{identity}”?

Ejecutamos el comando “Get-CsApplicationEndpoint” y en los resultados buscamos nuestra aplicación y copiamos el valor de la propiedad “Identity”

 

Fin de la historia

Cómo descargar documentos de Sharepoint rápidamente

Así como vimos una manera sencilla de publicar documentos en un servidor de Sharepoint (acceso), en esta ocasión vamos a proceder a la descarga de esos documentos.

En este proceso vamos a utilizar la clase “System.Net.WebClient” lo que implica que estas operaciones no son exclusivas de Sharepoint, sino que servirían ‘virtualmente’ para cualquier tipo de servidor web.

Al turrón

1. Instanciamos y configuramos el objeto “WebClient”:

   WebClient objWebClient = new WebClient();    
   objWebClient.Credentials = CredentialCache.DefaultCredentials;

2. Descargamos el documento:

   objWebClient.DownloadFile(txtSource.Text, rutaDes + "\\" + nombreArchivo);

Descargar sin permisos en la biblioteca de origen

En muchas ocasiones, las bibliotecas de Sharepoint que se utilizan como repositorio de aplicaciones tienen especificada una seguridad específica para evitar que el acceso a esa documentación se realice desde ‘fuera’ de las aplicaciones concretas. Para poder realizar el download en estos casos, tendremos que disponer de una cuenta de acceso ‘genérica’ a la biblioteca con los permisos mínimos para poder descargar documentación, y utilizar esa cuenta en la configuración de las credenciales del objeto “WebClient”:

objWebClient.Credentials = new System.Net.NetworkCredential("user","pwd","domain"); 

¿Fácil no?

Adjuntos

Descargar