The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” was not found

Dicho archivo .targets corresponde a un set de elementos, propiedades, targets y tareas de escenarios comunies segun se puede ver en la referencia de MSBuild. Estos archivos se instalan con el Visual Studio y/o MSBuild, sin embargo el correspondiente a WebApplication no está incluido.

Buscando si alguien más ha tenido este problema encontré esta nota “TFS 2010 – Solving The Imported Project Microsoft.WebApplication.targets Was Not Found Error”

En dicha nota sugieren literalmente copiar el directorio “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications” de una máquina de desarrollo al build server, acción que que la compilación suceda.

Al volver a ejecutar el build script comencé a obtener varios warnings indicando lo siguiente:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(847,9): warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.0″ were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Donde lo que procede es la instalación del SDK para la .NET Framework 4. Ojo, la Framework 4 se encontraba ya instalada en el servidor de integración, mas no el SDK, así que las referencias que utilizamos en nuestra aplicación, según lo indicaban los warnings,  se resolvían con el GAC, sin embargo, nuestro build no está completamente lipio. Una vez realizadas estas acciones tenemos ya nuestro “Build Success!”

Podemos descargarlo directamente de GitHub y para instalarlo tenemos 2 formas:

Importar el módulo en PowerShell e invocarlo directamente

Esto lo realizamos con las lineas:

Import-Module .\psake.psm1
Invoke-psake .\default.ps1

Debemos estar seguro que la execution policy nos permitirá ejecutar el módulo para ello podemos utilizar el comando de PowerShell

get-executionpolicy

y en caso necesitemos modificarlo, la sugerencia es establecer la policy “remotesigned”

set-executionpolicy remotesigned

Ejecutar el script de PowerShel psake.ps1

# call the psake.ps1 file directly
.\psake.ps1 .\default.ps1

Ejemplo de un script de psake

Algunos puntos clave

• Todo comienza con la task de nombre “Default”
• Es sugerible trabajar siempre con paths absolutos y para ello podemos apoyarnos en los comandos de PowerShell, por ejemplo: Split-Path en la función “Properties” que podemos observar en la documentacion de la estructura de un script psake
• Tenemos a disposición la gama de comandos de PowerShell y por ende la capacidad de extender nuestros build scripts, acá algunos links de referencia:
  • Starting Windows PowerShell
  • Using Windows PowerShell

Comenzando con mi investigación sobre Team Foundation Server me topé con algunos conceptos claves en un post de bharry, donde menciona  estas características y que resumo a continuación.

Team Project Collections

Cada colleción es un grupo de proyectos relacionados y cada TFS Farm  puede contener varias collecciones.
Cada colección es totalmente independiente una de la otra

Bases de Datos

Por la introducción de los Team Project Collections

TFS_Config

Base de datos raiz que centraliza los datos de la configuración del TFS incluyendo el listado de team project collections.

TFS_Warehouse

Contiene la información de reportes de todas las team project collections, con esto provee la capacidad de reporteria entre todas las team project collections en la TFS farm

TFS_*

Una base de datos por cada team project collection. La cual contiene toda la información operacional relacionada con un sub sitema para determinada team project collection (contol de versiones, seguimiento de ítems en trabajo, builds, etc).

TFS Farms

La introducción de las TFS Farms se considera un gran cambio de arquitectura, permitiendo mayor flexibilidad con relación al TFS 2008. Dichos cambios que dan vida a las TFS Farms son:

• soporte de NLB entre TFS application tiers. El habilitar balanceo de carga tiene como proposito habilitar una mas limpia y completa historia de alta disponibilidad.
• Scale out for SQL data tiers. Debido a que cada base de datos es independiente éstas pueden estar en cualquier SQL Server.

Antes de Realizar una Consulta vamos a crear un Indice, para ello utilizamos la intefaz web en la opción “indexes”

Luego utilizamos la opción “Create New Index”

al ver el formulario de creación

llenamos estos campos :

Por el momento las opciones de “Reduce” y personalización del índice no las utilizaremos.

Una vez creado el índice nos vamos a nuestro proyecto (el mismo del post anterior) y vamos a crear el método de búsqueda

Nos concentramos en la sentencia donde le decimos a la sesión que haremos una consulta de clientes sobre el índice “ClientsByName” que creamos previamente en nuestra RavenDB

Podemos darnos cuenta que “Query<Client>(string indexName)” es un “IRavenQueryable<Client>” con lo que podemos armar una expresión Linq, por lo que para efectos de prueba tenemos un “FirstOrDefault”

Una vez listo nuestro método lo utilizamos desde nuestra console application:

y al ejecutarla tenemos la salida:

Y para que puedan probarlo, aca esta el codigo fuente

Entre sus características tenemos

• Infraestructura Escalable
• Configuración en Windows Simple
• Transaccional
• Map/Reduce
• .Net Client API
• RESTful API
• Sharding
• Indexamiento (Lucene syntax)

En cuanto a documentacion parece estar bastante completa (en inglés), podemos consultar:

• Documentación de RavenDB en el sitio oficial
• Introducción a RavenDB en codeproject.com 

Antes de comenzar directamente con RavenDB si aún no tenemos en mente lo que una document database es podemos consultar la Wikipedia: Document-oriented database o también ver el video de la VAN de Alt.Net Hispano sobre NoSQL

Cabe mencionar que aún no puede correr en Mono y que los modos Servidor y Embedded corren bajo la framework .NET 4.0. El Cliente si corre (con algunas condiciones) en la framework .NET 3.5 y si puede correr en Mono.

Y para comenzar podemos ir directamente al clásico RavenDB HelloWorld! Tutorial

Según indica el tutorial, luego de descargar el build que decidamos, nos vamos al folder “server” y lo ejecutamos

Nota: Para este ejemplo modifiqué la configuración para que corriera en el puerto 8088, por default va a correr en el 8080.

Ahora que ya tenemos el servidor corriendo

procedemos a trabajar en una pequeña implementación utilizando el cliente de RavenDB, no olvidemos referenciar el cliente de Raven DB en nuestro proyecto.

Para esta prueba crearé una console application donde tendremos un par de clases que será la definición de nuestro documento:

Una vez teniendo nuestros POCO objects, procedemos a inicializar el DocumentStore y utilizarlo, para lo cual tendremos una clase más con un field que será el storage inicializado en el constructor y un método que se encargará de llenar el documento y almacenarlo en el storage.

Ahhh, no olvidemos que el inicializar el storage no es el único paso que debemos realizar. Para poder interactuar con los documentos necesitamos una sesión abierta, aquí el código:

Finalmente, utilizamos nuestro ClientsDirectory en una console application

y al ejecutar nuestra aplicación y luego irnos a la interfaz web de nuestro RavenDB Server

http://localhost:8088

Podemos ir a la sección “Documents” y bingo!

Nuestro primer documento creado, mismo que al darle click en la interfaz web podemos manipularlo:

No olvidemos que tenemos la opción de utilizar RavenDB embebido en nuestras aplicaciones lo cual nos quita la dependencia a un servicio adicional a nuestra aplicación que esté corriendo, adicionalmente que esto nos da libertad de utilizarla para muchos tipos de proyectos, no dejen de ver la sección Raven’s Client API

El proyecto puede descargarse Aquí

• Puede ser utilizada como una API de cache para almacenar objetos y variables de PHP.
• Tiene la opción de configurarse como Session Handler de PHP con persistencia en disco.

Entre las características que posee esta extensión estan:

• Cache del bytecode de PHP en memoria, agilizando el tiempo de respuesta al no tener que parsear completamente los scripts PHP, lo cual reduce tambien el I/O overhead.
• Debido a que la persistencia de los elementos en cache es en disco, situaciones como un Reciclado de los application pools no afectan en el cache ya creado.
• Soporta las notificaciones de cambio de archivos, permitiendo refrescar los bytecodes en cache.
• Cuenta con funciones de PHP para conocer el estado del cache.

Creo que es una buena alternativa a utilizar en IIS para mejorar el performance de nuestras aplicaciones en PHP reduciendo el tiempo de interpretación de los scripts.

Para mayores detalles de uso podemos consultar el Manual de PHP sobre Windows Cache y para otros recursos sobre la extensión pueden consultar el blog de RuslanY con el post original.

 VS 2010 productivity improvements, Part I

VS 2010 productivity improvements, Part II

VS 2010 Productivity Improvements, Part III

VS 2010 Productivity Improvements, Part IV

Entre las características que me llamaron la atención estan:

• Code Navigation
• Block Select and Block Edit
• Pin Tabs
• Multi-Monitor support

Y bueno, no dejo por un lado las extensions que podemos agregar y que pueden seleccionar desde la Galería

Al momento de realizar nuestros mapeos podemos manejar la composición simple manteniendo en una sola tabla las clasesque se relacionan

En este caso “PreInitSearchContext” esta compuesto por un “ContextCreator”.

Traduciendo esto a un Mapeo con FluentNhibernate utilizando “Component()” tendríamos algo así:

Y con esto estaríamos Manteniendo en la misma tabla “pre_init_search_context” ambas clases.

Ahora bien, resulta que existe otra clase que tambien tiene una relación de composición con “ContextCreator”, asi:

Imagino que pensaron en “reutilizar” el código del método Component que tenemos en la clase anterior… y aunque es una opción, estamos generando código repetido y obviamente cayendo en conflictos existenciales relacionados con mantenibilidad.

Es aquí donde “ComponentMap<T>” entra en juego, permitiendonos reutilizar el mapeo, en este caso del “ContextCreator”, entre las clases que sean necesarias

Queda entonces nuestro mapeo asi:

dejando en cada una de las clases solamente:

De esta forma las clases “PreInitSearchContext” y “SearchContext” con sus respectivos mapeos independientes pueden reutilizar el mapeo de “ContextCreator” el cual se traducirá a un par de campos (segun la clase utilizada en el ejemplo) en cada una de las tablas correspondientes.

A ver… C# nos dice que LAS CLASS INTANCES SON POR REFERENCIA MIENTRAS QUE LAS STRUCT INSTANCES(struct, enum, int, bool, chars… ) SON POR VALOR.

No voy a adentrarme esta vez en lo que implica el último párrafo con relación al uso de memoria o las struct instances y me enfocaré esta vez al título de este post: “C#: Objetos son por referencia…” con una pequeña Console Application.

Partimos de una clase que en si misma tendrá algunas properties y la responsabilidad de instanciarse a partir de un set de datos.

Adicionalmente, para efectos de ejemplo, utilizaré un pequeño contenedor con una Lista Generica de Objetos “MyClass” la cual comenzamos así:

Luego en nos vamos a nuestra console application, en donde primero creamos 2 instancias, es decir, tendremos 2 variables que apuntan a 2 objetos diferentes:

Cada una de las variables únicamente son apuntadores a los objetos. Con esto, cuando los enviamos como parámetros al método “AddAnMarkAsSaved”, dicho método estará modificando uno a uno y agregando dicha referencia a la Lista Genérica del Contenedor.

A este punto al ejecutar nuestra aplicación de ejemplo tenemos esta salida:

Una vez instanciado un objeto, las diferentes referencias que podamos tener al mismo, nos permitirán accesarlo, ojo… esto implica modificarlo… así que si pasamos por alto esto, podemos llegar a modificar “inconscientemente” el estado de un objeto cambiando lo que en nuestra aplicación realmente necesitamos.

Ohhh… Y entonces esto quiere decir que si extraigo el objeto de la lista que está en el contenedor y lo modifico, estoy cambiando el mismo objeto referenciado por las primeras variables?¿?¿? 

Respuesta: SI!

Veamoslo en código, primero agreguemos a nuestro contenedor el método que nos retorne un objeto MyClass por su Id:

Luego, si obtenemos de la lista el objeto cuyo Id sea el mismo que el objeto que referencia la variable “one” y le modificamos su “Comment” :

Sorpresa! accesando al objeto con las variables “one” y “objectFromContainer”

en ambos casos obtendremos el mismo “Comment”… Aca la salida de nuestro programa:

En resumen, cada vez que asignamos una variable donde hayamos instanciado un objeto a otra variable, o la pasamos como parametro a un método, lo que estamos haciendo realmente es ENVIAR UNA REFERENCIA a donde se encuentra el objeto en memoria. Es un juego de apuntadores donde podemos llegar a caer en problemas serios en nuestras aplicaciones si descuidamos este tema

Acá el link a la MSDN Library por si desean adentrarse un poco mas en este tema:

Objects (C# Programming Guide)

En este URL el código del ejemplo

La .NET Framework nos provee 2 herramientas Uri y el método ParseQueryString de la  HttpUtility cuyos detalles de documentación se encuentran acá:

• HttpUtility.ParseQueryString Method
• Uri Class

Demos una vista a la Uri Class, para esta clase debemos tener el namespace System incluido en nuestra clase. Luego de instanciarla pasando con el constructor el URL con el que vamos a trabajar, tenemos ya las diferentes partes accesibles por medio de atributos del objeto.

    var uri = new Uri(url);
    Debug.Write(uri.AbsolutePath);
    Debug.Write(uri.AbsoluteUri);
    Debug.Write(uri.Query);
    Debug.Write(uri.Host);
    Debug.Write(uri.Port);

Y ahora HttpUtility.ParseQueryString, este método es estático asi que podemos utilizarlo con habilitar el namespace System.Web

using System.Web;

como verán el método retorna una “NameValueCollection” cuyo comportamiento es como un diccionario (llave, valor).

No es que sea totalmente malo utilizar una ASPX, en realidad el punto es que toda ASPX hereda de System.Web.UI.Page y éste incluye ovehead que no necesitamos para lo que necesitamos.

Primero agregamos al proyecto nuestro Handler

Una vez creado, obtendremos el código definido por el template

Quien hace acá la magia es esta directiva:

Básicamente, define que la Clase “Handler” se debe instanciar para manejar la respuesta al llamar a dicho archivo.

Recordemos definir siempre el content type, el cual en este ejemplo definiré para javascript “application/x-javascript” y la respuesta (que para efectos de este post lo dejaré con un Response.Write) la modificaré para retornar un array en formato json, lo que nos lleva a una clase así:

public class Handler : IHttpHandler {
    public void ProcessRequest (HttpContext context) {
        context.Response.ContentType = "application/x-javascript";
        context.Response.Write("{testlist:['value 1','value 2', 'value 3']}");
    }
    public bool IsReusable {
        get {
            return false;
        }
    }

Al correr el scritp este es el resultado:

Aclaro… Existen formas para serializara diferentes formatos, para relacionarlo con el ejemplo pueden ver la documentación en msdn de Script Serialization

Algunos links sobre Session State y la opción de SQL Server Session Mode

Overview en CodePoject

How-To de Microsoft Support

Fast, Scalable, and Secure Session State Management for Your Web Applications

En ocasiones, al cambiar de servidor dado a la distribución que realiza un load balancer, la aplicación parecía no poder obtener la información almacenada en sesión y por ende no poder continuar con el proceso que debía desarrollar. Al momento de revisar la base de datos de sesión pudimos percatarnos que habían 2 tuplas para una misma ASP.NetSessionId

Query: select * from ASPStateTempSessions where SessionId like '%piltae45debwl355ek3v0545%'

Y cómo es esto? Ok, resulta que el SessionId que utilizamos en nuestra aplicación no es lo único que se utiliza como llave en la tabla de SQL ya que está formada por:

Session Id + Application Id

(ver mas info acá: Session State Providers)

Resultó entonces que por cada servidor nos estaba generando una tupla en nuestro storage de sesión, la primera con la información que habíamos almacenado y la segunda como una nueva sesión totalmente vacía. Esto debido a que a cada webserver le estaba asignando un diferente Application Id.

Me dirán por ahí que esto no debía suceder… también hay un trasfondo relacionado con la aplicación que casualmente permite esto, sin embargo esto lo dejamos para otro post

Solución:

Debemos irnos a cada uno de los webservers del WebGarden y en cada uno debemos definir el “ID” del website. Para ello debemos colocarnos en “Sites”

Dar click derecho y en “Manage Web Site” seleccionamos la opción “Advanced Settings”

y finalmente nos aseguramos que el Website en cada uno de los Web Servers de nuestro WebGarden tenga el mismo ID

Reiniciamos los IIS para que todo camine en orden y voila!

Extenderme a hablar de esta textutil de linux en su totalidad es mucho para un post, asi que por ahi irán saliendo uno que otro how-to de textutils.

Resulta que por algun motivo tenemos una cadena que necesitamos hacer pedazos a partir de un caracter en específico, por ejemplo un archivo con path de origen y destino para mover o copiar archivos, vamos a tomar de ejemplo lo que sería una linea del archivo

/home/fernando/hola.txt|/root/hola.txt

esto quiere decir que necesitamos una sentencia como esta:

cp /home/fernando/hola.txt /root/hola.txt

Acá es donde llega nuestro amigo AWK para plantearnos la solución a este dilema que viene a ser algo así:

echo "/home/fernando/hola.txt|/root/hola.txt" | awk '{split($1,arrayName,"|"); print "cp "arrayName[1]" "arrayName[2]}'

Especificamente quien hace la tarea es el comando “split” el cual tiene 3 parametros:

• Cadena de entrada ( $1 ) [Ver wikipedia el segmento del comando print  ]
• nombre del Arreglo ( arrayName ) , el conteo de posiciones comienza en 1.
• separador ( “|” )

Si tenemos varias lineas en un archivo de entrada en lugar del comando “echo” podemos utilizar “cat [archivo de entrada]” asi:

cat listado.txt | awk '{split($1,arrayName,"|"); print "cp "arrayName[1]" "arrayName[2]}'

La salida de este comando nos dará un listado de sentencias que podremos utilizar y ejecutar directamente, lo cual podríamos hacerlo con un apóstrofe invertido (`)

`echo "/home/fernando/hola.txt|/root/hola.txt" | awk '{split($1,arrayName,"|"); print "cp "arrayName[1]" "arrayName[2]}'`

Generalizando ambas realizan un redireccionamiento, sin embargo existen varias diferencias las cuales nos aclaran que cada una de las “opciones de redireccionamiento” tienen objetivos diferentes.

Response.Redirect

Basicamente envia al navegador una respuesta con headers de redireccionamiento a la nueva ubicación, la cual puede ser otra página en el mismo sitio, otro sitio en el mismo servidor u otro sitio externo.

Ejemplos:

Response.Redirect(“OtherPage.aspx”);  //Para otra página en el mismo servidor.

Response.Redirect(“http://www.google.com/”); // Para otro sitio, no necesariamente en el mismo servidor

Ojo, con un Response.Redirect estamos haciendo notorio al usuario que se le está cambiando de ubicación y por ende ve la nueva dirección en el navegador, en resúmen, el usuario realiza un nuevo Request.

Server.Transfer

La similitud con Response.Redirect es que también envía al usuario hacia otra página, sin embargo, existen varias características que enumero a continuación:

• Se conservan los recursos del servidor ya que solamente se hace un “focus”
• No se realiza ningún nuevo http request.
• Se mantiene el mismo URL en el browser del usuario.
• Tiene opción a mantener las colecciones del Formulario y QueryString.

Server.Transfer solamente funciona entre sitios corriendo en el mismo server

Ejemplo de uso:

Server.Transfer(“otherPage.aspx”);

Server.Transfer(“otherPage.aspx”,true); // si queremos mantener las colecciones QueryString y Form

Para mas detalles pueden avocarse al MSDN

HttpResponse.Redirect Method

HttpServerUtility.Transfer Method

Espero les sea útil este post

La configuración es bien sencilla, encontré más información utilizando nUnit y por ello que nace este post (ya era hora no? ) para ejemplificar utilizando xUnit

Primero comenzamos con las descargas e instalación de:

1. specFlow
2. watiN
3. xUnit

Adicionalmente a esto, deberán tener configurado el ejecutor de test units ya sea con TestDriven.Net o con Resharper en Visual Studio.

Ya que descargamos todo esto procedemos a crear un nuevo proyecto y a agregarle las referencias a las 3 librerias descargadas.

Ojo! Por default SpecFlow genera el código para ser utilizado por nUnit y pues resulta que queremos trabajar con xUnit… Casaca! (chapinismo para decir que algo es “simple, facil,…”) debemos agregar un Application Configuration File a nuestro proyecto con lo siguiente:

( mjm… creo que debo cambiar el theme de mi blog, les dejo el formato a ustedes por el momento )

Bueno, a este punto ya estamos listos para comenzar con nuestro primer test, para el cual tomaremos esta Feature:

Feature: googling
In order to use watin
As entusiast
I want to be able to get a page and validate text

Scenario: google to search about frogs
Given I have written URL in browser http://www.google.com
When I see google home page with title Google
Then I check if Advanced Search link appear


Cabe mencionar que SpecFlow utiliza como sintaxis Gherkin cuya documentación pueden encontrarla en http://wiki.github.com/aslakhellesoy/cucumber/gherkin 

Para utilizar esta feature debemos agregar un SpecFlowFeature File, el cual aparece entre los templates de visual studio si instalamos todo como nos indicaron los links que compartí al inicio.

una vez creada nuestra feature

ejecutamos la test unit, sabiendo que va a ser fallida y observamos el mensaje de salida:

cool! tenemos el código base para iniciar, entonces agregamos una nueva clase a nuestro proyecto con el código que SpecFlow nos mostró en el mensaje de error. A este punto comenzamos a interactuar con Watin.

No debemos olvidar la respectiva referencia a la libreria en los “using” de nuestra clase:

using WatinN.Core;

la forma de interacción con WatiN es bastante extensa, yo me enfocaré en lo que nuestra feature quiere probar, que el texto “Advanced Search” aparezca al obtener el URL. Si desean adentrarse mas en el ejemplo pueden ir directamente al sitio de WatiN

Por cada una de las sentencias de nuestro “Scenario” tendremos un método lo cual nos permite dividir las acciones o validaciones segun cada una de las sentencias. Para esta prueba dejemos la instancia del browser al momento del “Given” de nuestro “Scenario”, sin embargo tambien existen las opciones de tenerlo en un constructor, trabajar un metodo setup, entre otras. Nuestro código se puede ver algo así:

en el primer método se instancia el Watin para que utilice Internet Explorer y definimos la URL que se obtendrá, esto corresponde a nuestro “Given”.

Luego viene el “When” donde le inddicamos al Browser que obtenga la dirección que necesitamos evaluar.

Finalmente llegamos a la sentencia “Then” donde indicamos al browser que espere al texto que estamos buscando (esta en ingles y en español por la deteccion de idioma que tiene google) y adicionalmente se hace el “Assert” para verificar que se encuentre en el HTML. Esta validación, es muy relacionada a lo que queremos probar.

En este caso utilizo un “WaitUntilContainsText” porque la página de google pareciera mostrar con javascript estos textos, o al menos darles algun efecto, así que le digo a Watir que espere hasta que dicho texto se encuentre en el DOM. Lo cual nos indica que no importando si la página tiene javascript y a su vez este genera más elementos en el Dom, podemos realizar validaciones sobre el mismo.

No olvidemos cerrar el navegador al finalizar la ejecución desde código para evitar llenarnos de browsers con las ejecuciones de las pruebas

Aca está el código de nuestra clase:

using System.Text.RegularExpressions;
using TechTalk.SpecFlow;
using WatiN.Core;
using Xunit;

namespace testingIISInstance
{
    [Binding]
    public class StepDefinitions
    {
        private IE _browser;
        private string _httpAddress;
        [Given(@"I have written URL in browser http://www.google.com";
        }

        [Then(@"I check if Advanced Search link appear")]
        public void ThenICheckIfAdvancedSearchLinkAppear()
        {
            _browser.DomContainer.WaitUntilContainsText(new Regex("Advertising Programs|Programas de publicidad"));
            Assert.True(
                _browser.Html.IndexOf("Advertising Programs") >= 0 || _browser.Html.IndexOf("Programas de publicidad") >= 0
                );
            _browser.Dispose();
            _browser.Close();
        }

        [When(@"I see google home page with title Google")]
        public void WhenISeeGoogleHomePageWithTitleGoogle()
        {
            _browser.GoTo(_httpAddress);
        }
    }

Prometo continuar con este tema y desglosar con mejor detalle cada uno de los elementos acá mencionados