Registrar la .Net Framework

Esta es una operación sencilla para la cual tomaré como referencia una pregunta de stackoverflow.com que pueden ver en este link:

http://stackoverflow.com/questions/647598/how-to-register-asp-net-2-0-to-web-serveriis7

Podemos utilizar también Web Platform Installer segun se detalla en el siguiente punto: Instalar MVC 2.0

La opción más conocida es utilizar “aspnet.regiis.exe” el cual se encuentra en el path de la framework que estemos utilizando, por ejemplo para registrar la .Net Framework 2.0 en iis podemos utilizar:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe –ir

Cabe mencionar que la Framework 3.5 para ser utilizada en un website registramos la Framework 2.0 y en nuestro web.config referenciamos los assembly de la framework 3.5. Usualmente Visual Studio realiza esta configuracion por nosotros siempre y cuando la “targeting platform” sea la framework 3.5.

Instalar MVC 2

Para instalar MVC 2.0 es recomendable utilizar Microsoft Web Platform Installer , una vez lo tenemos instalado en nuestro IIS Manager seleccionamos el sitio web y buscamos el ícono de Web Platform Installer

Luego dentro de “Web Platform” seleccionamos la opción “Customize” dentro de “Frameworks and Runtimes”

Finalmente marcamos dentro de las opciones de “.NET Framework” lo que necesitamos (en este caso ASP.NET MVC 2)

Configurar el Website.

Para comenzar podemos dar click derecho en el folder “Sites” de nuestro server dentro del IIS Manager y seleccionar la opción “Add Web Site…”

Luego en el formulario de configuracion definimos el nombre del sitio, la ubicación de los archivos, la dirección IP a donde llegarán los requests y el nombre de dominio que utilizaremos.

Crear un “Wildcard Script Map” para MVC

Para esto seleccionamos el sitio web en nuestro IIS Manager y damos doble click en el ícono de “Handler Mappings”

Luego seleccionamos “Add Wildcard Script Map…” dentro del menú de acciones

y llenamos el form como se muestra a continuación…

Se recomienda utilizar el mismo Ejecutable que se tiene para el script map de “PageHandlerFactory”. Ojo, en el caso de que su sistema operativo sea 64 bit el path cambia. Por ejemplo:

Si el path donde tenemos instalada nuestra framework (32bit) es C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll podemos utilizar para 64bit el path C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll

Me atrevo a decir, que si tenemos dos script map para PageHandlerFactory como se muestra en la siguiente imagen:

seguramente necesitaremos crear dos wildcard script map para MVC

La creación de este wildcard script map es importante ya que MVC necesita que a los requests les sean aplicados los ruteos de nuestra aplicación.

Publicar Los Archivos de nuestro Website

“Para gustos se rompen generos” dicen por allí, asi que cada quien queda en libertad de seleccionar cuál es su forma preferida para colocar los archivos dentro del path definido al configurar nuestro sitio web, copiando los archivos, haciendo deploy con visual studio, etc…

La opción planteada es el uso de una clase “Maybe” la cual se puede descargar de codeplex la cual contiene los métodos para convertir cadenas de caracteres a Entero, Boolean, Byte, etc., asi:

Con esto evitamos el lidiar con las excepciones por cadenas con contenido “no convertible” con los “Convert” y tampoco agregamos sentencias condicionales, segun pienso innecesarias y que generan código repetido, por el uso del TryParse.

Una buena práctica que espero les sirva!

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

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

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

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