invocación de servicios web a traves de SQL server y .net

En el post anterior, hablábamos de como inyectar dlls a un sql server, en esta ocasión, y siguiendo con el mismo tema, comunicaremos un sql server con un servicio web delegando la comunicación en una dll.

Para comenzar a aplicar la solución se debe generar una solución limpia, y añadir un proyecto de aplicación WCF

wcfpost1

Como ya se ha comentado en otras ocasiones, un proyecto de WCF, es un proyecto de interfaz que define la interacción con la aplicación. En esta solución sería la fachada que exporta la funcionalidad.

Es importante la generación de un proyecto de test, que permita generar la pruebas y comprobar la funcionalidad de los servicios.

Creación de componente “dll”
Posteriormente se creará un proyecto dll, cuya única misión tener una referencia web al servicio y mantener la comunicación con el mismo.

wcfpost2

Después se procederá a agregar la referencia web. Hay que destacar que es necesario agregarla como referencia web y no como un cliente WCF, por problemas de interoperabilidad y de uso de .net framework (la librería System.ServiModel no es importable a sql server)

wcfpost3

 

 

 

Se hace click en “Advanced”:
Y por último se hace click en “add web Reference”wcfpost4

Se hace click en “Advanced”:
Y por último se hace click en “add web Reference”

wcfpost5

Al hacer click en “Add Reference”, genera una referencia web, que permite la comunicación con el servicio web.

Por último, dicho servicio se consumirá desde una función estática que permita facilitar su invocación desde un procedimiento almacenado.
Como ejemplo se muestra a continuación la generación de una clase que invoca al servicio web.

public class WebserviceInvoker
{
public static string Invoke( int param)
{
string result = string.Empty;
Service1 client = new Service1();
client.Url= “http://localhost/Optimissa.POC.SQLCRL.WCF/Service1.svc”;
result = client.GetData(param,true);

return result;
}

}

Anuncios

Inyección de dll en SQL Server

A veces hay que comunicar una base de datos con un programa, otras veces ampliar una BBDD con librerías que sean invocadas desde procedimientos almacenados… En definitiva, a veces se hace necesario inyectar dlls en SQL Server para que realice algo propio de .NET y no de BBDD.

Para realizar la operación crearemos un procedimiento almacenado CLR, es decir un procedimiento que ejecuta código .NET encapsulado en una dll.

Para ello, se añade un proyecto de base de datos.poc1

Y se añade un procedimiento almacenado CLR con c#
poc2

Una vez generado se procede añadir la librería generada en el paso anterior y a modificar el procedimiento para que pueda hacer uso de el

public partial class StoredProcedures{

[Microsoft.SqlServer.Server.SqlProcedure]

public static void SPPOCInvoker (int param1)
{
// Put your code here
try
{
SqlPipe sqlPipe = SqlContext.Pipe;
string result = Optimissa.POC.SQLCLR.BL.WebserviceInvoker.Invoke(param1);
SqlContext.Pipe.Send(result);
}
catch (Exception ex)
{
SqlContext.Pipe.Send(ex.Message);
}
}
}

Por último, se procede a compilar toda la solución y a abrir el SQL Management Studio, donde se crea una base de datos para probar el resultado de todo lo anteriormente expuesto.

Se procederá a ejecutar los siguientes scripts que se muestran a continuación:

  •   Habilita el uso de código manejado

alter database POCSQLCLR
set trustworthy on;
n  Habilitar el uso del CLR (Common Languaje Runtime de .NET)

EXEC sp_configure ‘clr enabled’, ‘1’;
RECONFIGURE;

  •   Registro de las librerías generadas

CREATE ASSEMBLY [POC.SQLCLR.BL]
FROM ‘D:\Projects\Pruebas de concepto\POC.SQLCLR.DataBase\bin\Debug\POC.SQLCLR.BL.dll’
WITH PERMISSION_SET = UNSAFE;

CREATE ASSEMBLY [Optimissa.POC.SQLCLR.DataBase]
FROM ‘D:\Projects\Pruebas de concepto\POC.SQLCLR\POC.SQLCLR.DataBase\bin\Debug\POC.SQLCLR.DataBase.dll’
WITH PERMISSION_SET = UNSAFE;

En este punto cabe destacar que, si alguna de las anteriores dlls falla por la necesidad de la inclusión de alguna librería del .net Framework, este se encuentra en la siguiente carpeta:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\

Y como se muestra se deberá ejecutar el siguiente script por cada una que no necesite

CREATE ASSEMBLY [POC.SQLCLR.BL]
FROM C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dl’
WITH PERMISSION_SET = UNSAFE;

  • Generación del procedimiento almacenado:

CREATE PROCEDURE [dbo].[SPPOCInvoker]
@param1 INT
AS EXTERNAL NAME [Optimissa.POC.SQLCLR.DataBase].[StoredProcedures].[SPPOCInvoker]

  •   Probar el resultado del procedimiento

EXEC [dbo].[SPPOCInvoker] 8;

Por último destacar que todas las librerías que se inyecten tienen que ser puras de .NET framework, no puede ser mixtas, por esa misma razón no se puede insertar el system.Servimodel, ya que esta depende de Microsoft.Transaction que no es nativa pura.

 

Espero que sea de utilidad!

Shims y Stubs en Microsoft Fakes

Hace un tiempo escribía sobre los fakes, como usarse y como sacarle partido. Los ejemplos estaban dirigidos casi exclusivamente a los stubs, y prometimos escribir un post con las diferencias entre Stubs y los Shims.

Para empezar diremos que ambos forman parte del framework de Microsoft, Microsoft Fakes, que tiene como objetivo el aislamiento del código y de los métodos que se quieren probar.

Para poder usarlo hay que tener en cuenta que es muy útil diseñar el código desde un primer momento con el objetivo claro de que se puedan realizar pruebas automáticas sobre el, si bien esto no es requisito indispensable y se pueden crear sustitutos de código al que no tenemos acceso o es de terceros.

¿Qué es un Stubs?

Es una pequeña clase que implementa el mismo interfaz que la clase a sustituir, de manera que injectada en una clase remplaza el funcionamiento normal de la aplicación sustituyendo la funcionalidad de la que depende por una porción contralada de la misma.

Por ejemplo un stub de un repositorio de usuarios, su método Get devolvería una lista de usuarios controlada sin tener que hacer el acceso a datos.

¿Qué es un shims?

Es un sustituto, se utiliza para ejecutar otro código en vez del que se esperaba para poder probar código sin necesidad de depender de código de terceros.

Podemos utilizar shims cuando nuestro código no depende de interfaces y el reemplazar un componente por otro se realizará a través de un sustituto.

Cuando utilizar un Stubs

Para poder utilizar Stubs, hay que pensar que nuestro código debe estar realizado de manera desacoplada, realizando una inversión de la dependencia.

De manera que el sustituto se puede inyectar en el método o clase a probar sin necesidad de refactorizar nuestro código, es decir, que el sustituto es inyectado y no instanciado dentro del método a probar.

Por lo tanto se utilizarán Stubs cuando nuestro código sea desacoplado, desarrollado pensando en pruebas (TDD) y nuestro método no instancie clases dentro de su código, sino que estas estén inyectadas.

 

No hay que olvidad que los Stubs son un método de aislamiento de código, que permite la inyección de una clase con el mismo interfaz que la original y cuyo resultado es controlado por el programador dotando a la aplicación de un entorno controlado en el cual la aplicación se encuentra en un estado y según ese estado debe devolver unos resultados.

Cuando utilizar un Shims

Los Shims son clases que solo deben usarse cuando se quiere probar código que de otra manera no sería posible probar.

No requiere que el código sea diseñado para que sea “testeable” o lo que es lo mismo no tiene por qué estar diseñado teniendo en cuenta las pruebas.

No requiera que sea inyectado como una dependencia, por lo que no requiere de un componente externo (como los frameworks de inyección de dependencias)

Los Shims interceptan el flujo de ejecución y sustituye el componente externo en otro deseado y comprobado.

Codigo de ejemplo en shims:

[TestMethod]

public void DateTimeTes()

{

using (ShimsContext.Create())

{

// Arrange:

System.Fakes.ShimDateTime.NowGet = () => { return new DateTime(2016, 2, 29); };

// Act

int result = MyCode.DoSomethingSpecialOnALeapYear();

// Assert

Assert.AreEqual(100, result);

}

}

 

Multiconfig para aplicaciones Windows

Etiquetas

Por regla general, para el desarrollo de aplicaciones disponemos de varios entornos, el entorno del desarrollador, entorno de pruebas, entorno de preproducción y entorno de producción. El objetivo es llegar a este último con el mínimo de errores (o con ninguno).

Esta disponibilidad de entornos, nos lleva a que distintas configuraciones convivan en el tiempo siendo cada una de ellas para un sitio distinto. Esta problemática se identificó hace ya tiempo en las aplicaciones web, pero puede ser deseable tenerla implementada en aplicaciones de escritorio como son los Windows Forms.

Hoy nos centraremos en que las aplicaciones Windows reconozcan la configuración de multiconfig y sea capaz de sobrescribir el app.config de la aplicación después de la compilación.

Disponemos de dos opciones:

  • Tradicional: se crea un app.config con todal las claves y se comentan las que no sean del entorno. Para cada despliegue hay que ir comentando y descomentando del archivo de configuración según proceda.
  • Crear un multiconfig que permita el despliegue en varios entorno, esta opción no solo es más elegante, sino que nos permite la comodidad de desplegar automáticamente con las configuraciones correctas simplemente eligiendo el entorno. Para este tipo se siguen los siguientes pasos:
  1. Edición del archivo de proyecto: crearemos una PropertyGroup por cada entorno, para ello copiaremos de las que nos vienen por defecto (debug o reléase) según queramos que la compilación sea en de una manera o de otra.

<PropertyGroup Condition=” ‘$(Configuration)|$(Platform)’ == ‘Debug|AnyCPU’ “>

<PlatformTarget>AnyCPU</PlatformTarget>

<DebugSymbols>true</DebugSymbols>

<DebugType>full</DebugType>

<Optimize>false</Optimize>

<OutputPath>bin\Debug\</OutputPath>

<DefineConstants>DEBUG;TRACE</DefineConstants>

<ErrorReport>prompt</ErrorReport>

<WarningLevel>4</WarningLevel>

<Prefer32Bit>true</Prefer32Bit>

</PropertyGroup>

<PropertyGroup Condition=” ‘$(Configuration)|$(Platform)’ == ‘Preproduccion|AnyCPU’ “>

<PlatformTarget>AnyCPU</PlatformTarget>

<DebugSymbols>true</DebugSymbols>

<DebugType>full</DebugType>

<Optimize>false</Optimize>

<OutputPath>bin\Debug\</OutputPath>

<DefineConstants>DEBUG;TRACE</DefineConstants>

<ErrorReport>prompt</ErrorReport>

<WarningLevel>4</WarningLevel>

<Prefer32Bit>true</Prefer32Bit>

</PropertyGroup>

 

Donde como dato más destacable podemos decir que “Preproduccion” utiliza la plataforma AnyCPU y que además se compila en Debug.

2- Añadir ItemGroup al archivo de proyecto: Crearemos la lista de configuraciónes a realizar a través de un ItemGroup tal y como mostramos a continuación:

<ItemGroup>

<!–Para el diseñador–>

<None Include=”app.config” />

<None Include=”App.Debug.config”>

<SubType>Designer</SubType>

<DependentUpon>App.config</DependentUpon>

</None>

<None Include=”App.Test.config”>

<SubType>Designer</SubType>

<DependentUpon>App.config</DependentUpon>

</None>

<None Include=”App.Preproduccion.config”>

<SubType>Designer</SubType>

<DependentUpon>App.config</DependentUpon>

</None>

<None Include=”App.Produccion.config”>

<SubType>Designer</SubType>

<DependentUpon>App.config</DependentUpon>

</None>

<None Include=”App.Release.config”>

<SubType>Designer</SubType>

<DependentUpon>App.config</DependentUpon>

</None>

</ItemGroup>

 

En el ejemplo podemos ver que se define un archivo por entorno y el archivo sobre el que actúa, es decir el archivo al que complementa. Aquí todos los archvo s de configuración actúan sobre el archivo App.config.

3- Coomandos de compilación: Por ultimo hay que hacer que al compilar sobre escriba el archivo de configuración general, para ello utilizaremos los siguiente elementos, que se definen hacia el final del archivo de proyecto. Estos elementos son para poder recuperar las herramientas de compilación y sobreescritura del app.config general.

Configuración para C#.

<Import Project=”$(MSBuildToolsPath)\Microsoft.CSharp.targets” />

 

<Target Name=”AfterBuild”>

<PropertyGroup>

<TempFile>$([System.IO.Path]::GetTempFileName())</TempFile>

</PropertyGroup>

<Copy SourceFiles=”@(AppConfigWithTargetPath)” DestinationFiles=”$(TempFile)” />

Comando de postcompilación. Aquí definimos el archivo temporal que será la salida del resultado de la transformación del entorno de configuración.

<TransformXml Source=”$(TempFile)” Transform=”$(ProjectConfigTransformFileName)” Destination=”@(AppConfigWithTargetPath->’$(OutDir)%(TargetPath)’)” />

<Copy SourceFiles=”@(AppConfigWithTargetPath->’$(OutDir)%(TargetPath)’)” DestinationFiles=”App.config” />

Copia al archivo de configuración final.

</Target>

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets” />

Preprocesador de config, llama la atención que sea de la versión v10.0, pero realmente es así. No hay que intentar forzarla a nuestra versión actual de visual studio.

<PropertyGroup>

<ProjectConfigFileName>App.config</ProjectConfigFileName>

</PropertyGroup>

<Import Project=”$(MSBuildBinPath)\Microsoft.CSharp.targets” />

 

Como ya se ha comentado, esta configuración es típica de sitios web. Por lo que, por sí sola no es suficiente. Si ha llegado hasta aquí y sigue sin funcionar, hay que decirle al entorno como se compila cada uno de los proyectos.

4- Configuración del ConfigurationMananger: Desde el archivo de solución sacamos el ConfigurationMananger y asignamos la configuración a los proyectos. Si no aparece alguno hay que crearlo pero sin marcar la casilla de crear configuración, ya que esto lo hemos hecho en el primer paso al configurar el archivo de proyecto.

img2

img1

Con esto, cuando compilemos, nos dirá que ha sobreescrito el app.config y si queremos recargarlo (siempre y cuando esté abierto el app.config) y podremos ver como en cada despliegue se despliega con su configuración pertinente.

Un saludo y espero que sea de utilidad.

Pruebas unitarias on Mirosoft Fakes:

Etiquetas

, , ,

Hoy dia la importancia e los test unitarios es algo que no tiene discusión, cada vez más los desarrollos van incorporando estas pruebas que hace unos años nos podrían sonar a cosas raras.

Lo cierto es que es una buen forma para testear las aplicaciones, y lo que es más es una forma de desarrollar documentando lo que hace un programa. Como dice Bruno Capuano “un programa hace lo que dicen sus pruebas unitarias”.

Ahora bien, cuando nos ponemos a realizar las pruebas podemos caer en el error de querer ahorrar tiempo de desarrollo de pruebas haciendo pruebas que invoquen a un método que invoca a otro o incluso se conecta a la base de datos.

Este error es tal, porque estamos haciendo dependientes nuestras pruebas de la base de datos y de que esté levantada y funcionando correctamente. También es un error porque estamos viendo como este método se comunica con otro y por tanto nuestra prueba depende del buen funcionamiento del método intermedio.

Para evitar eso, podemos hacer uso de Microsoft.Fakes. Esta librería nos permite falsear una librería haciéndola que devuelva lo que queramos, para probar un método que suma una lista de enteros es más fácil que podamos probar con una lista de tres elementos que sabemos lo que suman que con una columna de una tabla de la base de datos que puede variar y que las pruebas fallen o sean dependientes de los valores de dicha tabla.

Pues bien, creo que la problemática está bien clara y por lo tanto vamos al grano.

En nustro ejemplo vamos a falsear un repositorio que en su método GetQuantities, nos devuelve una lista de enteros que debemos sumar (Es cierto, podríamos haber hecho un List.Sum(x=>x.Quantity), pero para el ejemplo nos valdría.

En la prácitca deslegaremos las referencias de nuestro proyecto y hacemos click con el botón derecho sobre la referencia de infraestructura de datos. Elegimos la opción de Add Microsoft.Fakes.

y vemos que se nos añade una referencia y otra en la carpeta de Fakes.

a partir de ahora en nuestro código instanciaremos un stub del repositorio.

IRepositorySub myfakeRepository=new RepositoryStub();

luego falsearemos el método que invocará..

myfakeRepository.GetQuantities=()=>{

list.Add(1);

list.Add(4);

return list;

};

Posteriormente en la prueba de test haremos;

[TestMethod]

public void mytest(){

Iclase obj=Ioc.Resolvez<IClasa>();

int result=obj.sum();

Assert.AreEqual(5,result);

}

y con eso tenemos probado el método.

Espero que haya sido ilustrativo, espero poder contar con tiempo para podre contaros en detalle que es un stub y un shims.

Unit Test para métodos internos.

Etiquetas

, ,

Hoy en día nadie ponen en duda la utilidad de las pruebas unitarias, y de la importancia del incremento de la cobertura de código.

Atrás quedaron los días en los que la gente tildaba de perdida de tiempo la creación de pruebas automáticas e incluso se atrevían a criticar su utilización así como las metodologías agiles que se con fundamento en estas pruebas.

 

Hoy mas que ponernos nostálgicos quería resaltar la importancia de las pruebas automáticas y dar una herramienta más que nos permita aumentar nuestra cobertura de código sin tener que violar el encapsulamiento y otras propiedades de la Programación Orientada a Objetos.

Para empezar mostramos el caso de prueba de un método interno, el cual queremos probar ya que es la base de una funcionalidad.

Para ello debemos encapsular el objeto dentro de otro e invocar sus métodos privados a través de un invocador.

PrivateObject accessor = new PrivateObject(instantObject); 

var lst = accessor.Invoke(“PrepareData”,param1); 

 

Como se muestra en el ejemplo con la clase PrivateObject encapsulamos la instancia de nuestra clase y luego ejecutamos el método PrepareData con el parametro1. Su resultado es el resultado que obtendríamos si la ejecutásemos directamente si su visibilidad fuese pública.

 

Hasta aquí el post sobre invocación de métodos privados para pruebas unitarias. Espero que sea de utilidad y dejamos para otro post la independización de codigo basado en Microsoft.Fakes.

CRUD CON DEVEXPRESS GRIDCONTRL

Etiquetas

,

En el actual proyecto en el que estoy inmerso, nos hemos encontrado con la necesidad de realizar operaciones CRUD con los controles de devexpress. Hasta ahora eran pantallas con pocos campos, pero al llegar a una hemos visto que eran suficientes como para intentar evitar crear una nueva ventana de edición. Investigando un poco por la red, nos encontramos con propiedades como “Edit mode” y events como RowUpdated, dichos elementos nos servirán para crear nuestro CRUD de manera más sencilla y eficiente. En este post, veremos un tutoríal para realizar estas operaciones de forma sencilla. SELECT: Para realizar un select y mostrar los campos en el grid, crearemos (según nuestra arquitectura) los método necesarios para que nos devuelvan los datos que mostraremos en el grid. Posteriormente arrancaremos el designer para crear las columnas y asignarle los campos en la propiedad FieldName.

ACTUALIZACIÓN:

Para realizar las actualizaciones, lo que haremos será activar la propiedad de la vista “edit mode” para ello la establecemos a “editForm”. Con esto lo que hacemos es que se genere una pantalla modal de forma automática la cual tiene dos botones, uno de “update” y otro de “cancel”. Esto permite lanzar la pantalla modal de forma automática cuando se hace doble click sobre el grid y cuando se realiza la modificación actualiza la fila que hemos editado. Si queremos persistir los cambio de forma manual capturaremos el evento de la vista “gridView1_RowUpdated”.

imgEditForm

Añadir

Para añadir un elemento, la idea es crear una fila vacía, y lanzar la pantalla en edición sobre esa fila, esto nos permitirá que la ventana de edición esté en blanco y modificaremos sus campos. Una vez modificados se lanzará el evento anteriormente mencionado. El código será el siguiente: List lsd = new List(); Infraestructure.Entities.Views.UCGrid item = new Infraestructure.Entities.Views.UCGrid(); lsd.Add(item); lsd.AddRange((List)grdfunds.DataSource); grdfunds.DataSource = lsd; gridView1.FocusedRowHandle = 0; gridView1.ShowEditForm();

Borrar

Para borrar haremos como solemos hacer siempre, elegimos la fila que tiene el foco, y la eliminamos, por último refrescamos el grid. private void XgrdCxx_FocusedRowChanged(object sender, DevExpress.XtraGrid.Views.Base.FocusedRowChangedEventArgs e) { try { //Elige la fila seleccionada xxInitialGrid rowData = (xxInitialGrid)XgrdCartas.GetRow(e.FocusedRowHandle); this.SelectedData = rowData; } catch(Exception ex) { //Esta excepción no debe ser lanzada, sino tratarla y mostrar un aviso al usuario. Exception outEx; if (EntLib.HandleExceptionUI(ex, out outEx)) { fAlert alerta = new fAlert(fAlert.TIPOS_ALERTAS.WARNING, “Error”, Infraestructure.Localization.GlobalMessages.ucxxAlertErrorSeleccion); alerta.ShowDialog(); } } }

 

Y esto es todo! Un saludo y espero que sea util.

PRIMEROS PASOS CON VNEXT

Hace poco salió la segunda versión de prueba del nuevo ASP.NET (Vnext). En este artículo queríamos hacernos eco de cómo se puede empezar a trabajar en esta novedosa plataforma y para ello lo mejor es instalarse la beta del Visual Studio 14 y abrir una solución para analizarla.

El primer paso cuando nos generamos una aplicación web en el Visual Studio 14, es elegir la plantilla aplicación web Vnext. Esto generará un proyecto en ASP MVC el cual contiene un archivo html con enlaces para complementar tu solución (Project_Readme.html), dentro de estos enlaces encontramos los de EntityFramework 7, la cual tiene como gran novedad que puede ejecutarse en varias plataformas (Linux, MAC, Windows).

img1Post

Con esto tendremos solucionado el acceso a motores de base de datos (no solo relacionales), y unido al proyecto web, podemos generar varios proyectos de tipo ClassLibrary, que nos aporten una mayor consistencia a la solución, estos proyectos deben ser también de VNEXT y utilizar así las ventajas que este nuevo Framework tiene.

En esta versión de Visual Studio destaca la inclusión por defecto de Bootstrap, el framework Css que nos permite trabajar y maquetar nuestras web para todos los navegadores. Así como el poder usar SignalR o web sockets.

Hay que destacar que el framework que estamos comentando está en Alpha2, es decir que es susceptible de varias modificaciones.

VNEXT es opensource y está disponible en codeplex de manera que si eres un gran apasionado por la tecnología puedes descargártelo y hacer tus aportaciones a este nuevo Framework de desarrollo.

img2Post

Como conclusión a este primer post de VNEXT podemos decir que Microsoft está apostando por un modelo más abierto de su plataforma, orientado a la red, y que los desarrolladores puedan trabajar con la plataforma .NET con independencia del Sistema Operativo en el que vaya a correr nuestra aplicación. Como sorpresa en esta nueva versión nos encontramos con aplicaciones de consola en VNEXT, las cuales pueden ser de gran utilidad si pensamos en tareas programadas en cualquier plataforma.

 

 

Controles fuertemente tipados en asp.net 4.5

Etiquetas

Hace ya unos años escribí en mi antiguo post este tema, hoy lo he querido traer aqui que es donde debe estar.

Ademas actualizaré alguna cosilla que ha salido en la versión 4.5 definitiva.

El problema de la seguridad en internet, siempre ha sido un tema prioritario para los desarrolladores, por eso, los grandes esfuerzos de las compañías en sacar frameworks cada vez más potentes y seguros. Hoy nos orientamos a mostrar uno de esos esfuerzos que vendrá incorporado en la nueva versión de ASP.NET 4.5

Hoy queremos hacernos eco de una característica, que a nuestro modo de ver es un gran avance,  y que tendrá una gran repercusión tanto en la seguridad, como en los tiempos de respuesta de nuestras aplicaciones. Nos referimos la posibilidad de tipar fuertemente los controles enlazados a datos. Y para ello veremos un ejemplo con el control que más flexibilidad nos proporciona, pero a la vez que más complejidad requiere: El repeater.

El repreater es un control, que nos permite repetir una especie de plantilla con cada elemento enlazado dentro del datasouce. Esta característica, que es de gran utilidad, hacía uso de un enlazado de datos dinámico, lo que daba una gran flexibilidad a este control, pero a la misma vez podía aumentar el  riesgo de crear vulnerabilidades por XSS (Cross-Site Scripting).

Si ya es verdad que se dieron pasos para solucionar este problema en asp.net 4.0, ahora con el tipado fuerte de datos se ha conseguido un gran avance (ya que no nos gusta decir en material de seguridad que algo es definitivo)

En estas líneas podemos observar cómo se hace el linkado de datos al campo text a través de las instrucciones <%#Eval(‘xxx’)%>. Este código es potencialmente peligroso, ya que es vulnerable a XSS.

<asp:Repeater  ID=”rptEjemplo1” runat=”server” >

<ItemTemplate>

<asp:Label runat=”server” ID=”lblComentario” Text=’<%# Eval(“Comments”) %>’/>

<asp:Label runat=”server” ID=”lblNombre” Text=’<%# Eval(“Name”) %>’/>

<asp:Label runat=”server” ID=”lblEmail” Text=’<%# Eval(“Email”) %>’/>

</ItemTemplate>

</asp:Repeater>

 

Ahora tendremos esto mismo, pero lo haremos estableciendo una nueva propiedad (ItemType) y cambiando las etiquetas peligrosas por estas otras

 <%#Item.Clientes.Email%>

En el que al estar tipado el control no admitirá valores que no estén contemplados en la clase que se establece como tipo del control.

Así el ejemplo anterior nos quedará de esta forma:

<asp:Repeater  ID=”rptEjemplo1” runat=”server” ItemType=”Clientes”  >

<ItemTemplate>

<asp:Label runat=”server” ID=”lblComentario” Text=’<%#Item.Clientes.Comments %>’/>

<asp:Label runat=”server” ID=”lblNombre” Text=’ <%#Item.Clientes.Name %>’/>

<asp:Label runat=”server” ID=”lblEmail” Text=’ <%#Item.Clientes.Email %>’/>

</ItemTemplate>

</asp:Repeater>

La gran flexibilidad que nos da el repeater, se ve a veces contrarrestado por la seguridad, por ello es de necesidad, que los desarrolladores conozcamos tanto los puntos fuertes como los débiles de los controles que usamos. En este punto los esfuerzos de la compañía de Redmond han sido constantes, tanto en la versión 4, donde se realizaron grandes esfuerzos como en la versión 4.5 con el tipado fuerte de datos en controles. Desde aquí animar a que se vayan probando y conociendo las nuevas características que nos traerá el nuevo asp.net 4.5

un saludo a todos

Configurar una aplicación para que sea compatible con IE9

Después de un tiempo sin poder escribir, voy a aprovechar una breve pausa para comentar un aspecto que últimamente resulta de gran utilidad.

Para empezar vamos a enunciar la problemática que resolvemos:

Todos los que utilizamos ASP.NET para hacer nuestras páginas web, solemos hacer uso de los updatepanel para realizar llamadas asíncronas al servidor (Ajax de .ASP.NET). Esto en IE9 no conlleva ningún problema, pero si utilizamos el IE10 o IE11, vemos que hay ciertas cosas que dejan de funcionar.

El problema es que estos nuevos navegadores se han creado pensando en HTML5, pero se ha descuidado la compatibilidad hacia atrás. El primer acercamiento que se puede intentar es el ejecutar el navegado con el modo de compatibilidad para intentar que se comporte como el IE9, pero esto no soluciona todos los problemas.

La mejor opción es meter una serie de instrucciones en el web.config que obliga al navegador y a la aplicación a que funcione como si fuese un IE9.

<httpProtocol>

<customHeaders>

<clear />

<add name=”X-UA-Compatible” value=”IE=9″ />

</customHeaders>

</httpProtocol>

 

Esto es dentro de la etiqueta <system.webServer>.

Como resumen, de este post, hablaremos de que esta solución nos permite adaptar nuestras aplicaciones a los nuevos navegadores, sin que por ello tengamos que hacer costosos cambios en ellas.