ASP.Net Security

tecnologias ASP.NetMake sure you are very familiar with the following terms:

  • Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers.
  • Authorization. Defining what authenticated clients are allowed to see and do within the application.
  • Secure Communications. Ensuring that messages remain private and unaltered as they cross networks.
  • Impersonation. This is the technique used by a server application to access resources on behalf of a client. The client’s security context is used for access checks performed by the server.
  • Delegation. An extended form of impersonation that allows a server process that is performing work on behalf of a client, to access resources on a remote computer. This capability is natively provided by Kerberos on Microsoft® Windows® 2000 and later operating systems. Conventional impersonation (for example, that provided by NTLM) allows only a single network hop. When NTLM impersonation is used, the one hop is used between the client and server computers, restricting the server to local resource access while impersonating.
  • Security Context. Security context is a generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread. The attributes from a process’ logon session and access token combine to form the security context of the process.
  • Identity. Identity refers to a characteristic of a user or service that can uniquely identify it. For example, this is often a display name, which often takes the form authority/user name.


There are a number of overarching principles that apply to the guidance. The following summarizes these principles:

  • Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges.
  • Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
  • Don’t trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, cross-site scripting attacks, and buffer overflow.
  • Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.
  • Don’t rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it’s better to use platform features or proven techniques for securing your data.
  • Check at the gate. You don’t always need to flow a user’s security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller’s security context all the way through to your application’s data tier.
  • Assume external systems are insecure. If you don’t own it, don’t assume security is taken care of for you.
  • Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don’t expose any more information than is required when returning an error message to the end user.
  • Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don’t include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
  • Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.
  • If you don’t use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn’t use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

The following steps identify a process that will help you develop an authentication and authorization strategy for your application:

  1. Identify resources
  2. Choose an authorization strategy
  3. Choose the identities used for resource access
  4. Consider identity flow
  5. Choose an authentication approach
  6. Decide how to flow identity

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Libreria empresarial del grupo de patrones y practicas de Microsoft

La última versión de la Enterprise Library del grupo de Patterns and Practices de Microsoft se libero en mayo del 2007 y es compatible con .Net 2.0 y 3.0.

Información actualizada y material didactico se puede localizar en el sitio comunitario de la libreria empresarial.

Enterprise Library: La evolución de los .NET Application Blocks de patterns & practices

Entlib – Enterprise Library es la evolución de los Bloques Aplicativos .NET que han sido desarrollados por el Grupo PAG (Microsoft Platform Architecture Guidance) dentro de Microsoft. Este grupo genera guías y arquitecturas de referencia, patrones de diseño, y código fuente desarrollado con la implementación de diversos escenarios tecnológicos.

Los desarrolladores en su momento puden usar la guía para comprender las mejores prácticas referenciadas y sugeridas por Microsoft para aplicaciones .NET; o incorporar el bloque aplicativo como tal dentro de sus desarrollos, en su formato original y/o extendido.

Los “Bloques Aplicativos .NET” que en su momento fueron liberados son los siguientes:

Por la forma gradual en que fueron desarrollados dichos bloques aplicativos, los mismos estaban desintegrados y la experiencia de utilización e extensibilidad eran diferentes entre si. Además que la utilización de cada uno de dichas piezas de software obligaba a la instalación de componentes de software independientes.

Con estas áreas de oportunidad la nueva versión de los “.NET Application Blocks” se integró con la nueva etiqueta de Enterprise Library. El grupo de PAG ha anunciado lo siguiente:

Entlib es una librería de activos de software reutilizable que atenderá los retos comunes en el desarrollo del software empresarial.

Entlib está focalizado en la consistencia, extensibilidad, fácil utilización e integración de los diversos bloques aplicativos existentes y futuros.

Es importante aclarar que Enterprise Libray no es un producto como tal, sino que es un componente de software que es proporcionado como está, pero del cual se puede contratar soporte directamente de Microsoft, tratado bajo un esquema parecido al código escrito por los usuarios.

Recursos relacionados:

  1. Web Service Software Factory
  2. Smart Client Software Factory
  3. Web Client Software Factory
  4. Guidance Automation Extensions and Guidance Automation Toolkit


  • Sistema oprativo: Windows Server 2003; Windows Vista; Windows XP

Note: If you already have the Enterprise Library 3.0 installed, you must uninstall it before installing the Enterprise Library 3.1. However, you can install the Enterprise Library 3.0 or the Enterprise Library 3.1 when 2.0 is already installed.

  • Microsoft .NET Framework 2.0 or 3.0. You need .NET Framework 3.0 for the
    Application Block Software Factory and the WCF adapters for the Validation
    Application Block and Exception Handling Application Block
  • Microsoft Visual Studio 2005 development system (any of the following

    • Microsoft Visual Studio 2005 Standard Edition
    • Microsoft Visual Studio 2005 Professional Edition
    • Microsoft Visual Studio 2005 Team Edition for Software Developers
    • Microsoft Visual Studio 2005 Team Edition for Software Testers
    • Microsoft Visual Studio 2005 Team Edition for Software Architects
    • Microsoft Visual Studio 2005 Team Suite

  • To use the Application Block Software Factory and the Strong-Naming
    Guidance Package, you need the Guidance Automation Extensions (GAX). To
    modify these guidance packages, you also need the Guidance Automation
    Toolkit (GAT).
  • Some blocks and samples require the use of Microsoft SQL Server or other
    database products.
  • Visual Studio Team System or NUnit 2.2 is required if you want to
    execute unit tests.


Enterprise Library 3.1 – May 2007

Juan Carlos Lozada’s WebLog


More Information


  Enterprise Library
The patterns & practices Enterprise Library is a library of reusable and extensible application blocks designed to assist developers with common enterprise development challenges. Enterprise Library 3.0 contains application blocks for Caching, Cryptography, Data Access, Exception Handling, Logging, Policy Injection, Security and Validation.
  Caching Application Block
The Caching Application Block is a component of Enterprise Library which provides a flexible and extensible caching mechanism for use in client and server-side .NET development projects.
  Smart Client – Composite UI Application Block
Are you building applications with complex user interfaces? Do you want to take full advantage of the power of the Microsoft Windows desktop? Check out this recently released application block that provides guidance on building world-class, enterprise ready, client applications. Available both in C# and Visual Basic .NET.
  Cryptography Application Block
The Cryptography Application Block is a component of Enterprise Library which makes it easier to include cryptographic functionality in .NET applications. The block provides a simple interface to DPAPI, symmetric encryption and hashing, and uses the Enterprise Library configuration tool to simplify key management.
  Data Access Application Block
The Data Access Application Block is a component of Enterprise Library which reduces the amount of custom code that you need to create, test, and maintain when building data access layers in .NET applications.
  Exception Handling Application Block
The Exception Handling Application Block is a component of Enterprise Library that makes it easier to implement consistent exception handling policies at logical tiers in an application. Exception policies can be configured to perform tasks such as logging exceptions, wrapping or replacing exception types.
  Logging Application Block
The Logging Application Block is a component of Enterprise Library that allows developers to instrument their applications with logging and tracing calls. Log and trace messages can be filtered, formatted and routed to a choice of trace listeners, including the event log, text files, database or WMI.
  Policy Injection Application Block
The Policy Injection Application Block is a component of Enterprise Library which allows developers to specify the crosscutting behavior of objects in terms of a set of policies. Crosscutting concerns are the necessary tasks, features, or processes that are common across different objects. Examples are logging, authorization, validation, and instrumentation.
  Security Application Block
The Security Application Block is a component of Enterprise Library that builds on the capabilities of the Microsoft .NET Framework to help you perform authentication, authorization, check role membership and access profile information.
  Validation Application Block
The Validation Application Block is a component of Enterprise Library which provides a common approach to defining validation rules for your business objects that allows them to be reused across different layers of your application.
  Web Service Facade for Legacy Applications
This guide discusses best practices for interfacing with legacy applications by using Microsoft® ASP.NET Web services and the Microsoft .NET Framework. The .NET Framework provides the foundation for creating a Legacy Application Interface solution using Microsoft technologies. This guide provides a sample solution using a Microsoft FoxPro® database as the legacy application and connecting it to a .NET-based application using ASP.NET Web services and SOAP. The specific technologies involved are ASP.NET, C# or the Microsoft Visual Basic® .NET development system, the .NET Framework, XML, Visual Basic, COM, and ADO.

La reutilización de código

Ahora, como antes, más que antes, como siempre, la reutilización de código se presenta como un valor fundamental en el desarrollo de sistemas. Uno de sus aspectos es la interoperabilidad de los códigos. Por decirlo de alguna manera, la compatibilidad de una aplicación con diferentes versiones de un sistema operativo y con diferentes sistemas operativos.

Por un lado Microsoft, por otro los demás. El imperio contra los rebeldes republicanos y los feudos vecinos. Pero dentro del mismo imperio se hablan distintas lenguas y los rebeldes tienen diferentes agendas.

Una aplicación que trabaja en Windows 95 no necesariamente funciona en Windows XP, Visual Basic 6 y Visual Basic .Net son animales distintos. Una aplicación Linux que funciona en la distribución Red Hat no necesariamente funciona en la distribución SuSe. La frase platform independent source en la practica marca una prueba de iniciación para hechiceros.

En el caso de Microsoft, algunas de estas incompatibilidades son de origen mercadológico. ¿Cuál es la diferencia entre Windows XP Home Edition y Windows XP Pro? Limitaciones artificiales en la versión casera con respecto a la versión profesional. Desde el punto de vista de Microsoft este modelo funciona, Vista no tiene 2 versiones distintas sino n, cada una definida por un segmento de mercado. Las utilidades de MS aumentaron 65% con respecto al año pasado y podemos esperar más de lo mismo por lo menos en el corto plazo.

En el caso del movimiento Open Source las incompatibilidades son de origen sociocultural. Distintos grupos trabajan con combinaciones distintas de herramientas y enfoques metodológicos. Estos herramentales se yuxtaponen unos con otros y las combinaciones son infinitas. La versión de gcc pude ser la diferencia clave para que un paquete se construya correctamente.

Una iniciativa que no termino de entender es Mono. El concepto es bueno, pero ya va un par de veces que trato de construir una aplicación .Net para fallar miserablemente. Al revisar la letra chiquita del readme aparece que la aplicación es Mono ¿Cuál es el caso de incluir archivos de solución y proyecto de Visual Studio si VS no puede construir la aplicación? ¿Si se requiere reproducir el ambiente de trabajo del desarrollador con librerí­as y variables de entorno porque no documentar esas dependencias? Entiendo que son pecadillos del bien intencionado pero se me escapa la motivación fundamental del chango.

Un aspecto problemático del desarrollo í­nter plataforma son las interfaces graficas de usuario (GUI). Cada sistema operativo tiene su look-and-feel caracterí­stico y el manejo eficiente de ventanas requiere el uso del API nativo correspondiente.

Un enfoque que se puede tomar es agregar una capa intermedia entre la aplicación y el sistema operativo que abstraiga la interacción entre la capa lógica y la interfase grafica a cambio de una penalización en el rendimiento. Algunos problemas que se pueden presentar con librerí­as de este tipo:

  • El uso de una capa intermedia adicional disminuye el rendimiento de la aplicación.
  • La librerí­a necesaria para soportar la funcionalidad adicional de múltiples sistemas operativos aumenta le tamaño de las aplicaciones más alla de lo que se justifica con la funcionalidad de la aplicación misma. Por lo mismo el soporte para plataforma móvil no es adecuado
  • La apariencia de la aplicación no corresponde a la de una aplicación nativa y los diálogos son distintos a los que los usuarios usan normalmente.
  • La necesidad de definir un mí­nimo común denominador hace que se pierda la oportunidad de usar las características más avanzadas de un sistema operativo en particular.
  • El uso de librerí­as fuera de la esfera de influencia del sistema operativo anfitrión saca a la aplicación del ciclo de vida del mismo y dificulta el proceso de mantener alineadas las actualizaciones de la aplicación con cambios en el sistema operativo.

La tabla siguiente muestra un comparativo de librerí­as para desarrollo ínter plataforma.

Liberarí­a Tamaño (MB) Tamaño comprimido (MB)
Java 30+ 15
GTK+ 9+ 4
QT 4+ 2
wxWidgets <1 <.5

Java es una norma abierta que funciona bien como propuesta í­nter plataforma. La maquina virtual de java (JVM) aísla la aplicación del sistema operativo anfitrión y esta disponible normalmente en todas partes. Sin embargo las aplicaciones de java tienden a ser chupa recursos. Si revisas los procesos en una estación XP con Firefox instalado, Firefox es normalmente el campeón en memoria utilizada.

GTK+ es un grupo importante de bibliotecas o rutinas para desarrollar interfaces gráficas de usuario (GUI) para principalmente los entornos gráficos GNOME, XFCE y ROX de sistemas Linux. GTK+ es la abreviatura de GIMP toolkit (conjunto de rutinas para GIMP). Es software libre (bajo la licencia LGPL), multiplataforma y parte importante del proyecto GNU. Inicialmente fue creado para desarrollar el programa de manejo de imágenes GIMP, sin embargo actualmente es muy usada por muchos otros programas en los sistemas GNU/Linux. Cabe mencionar que Qt es una alternativa a GTK que también es muy utilizada (en el entorno KDE, por ejemplo).

GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, Java (Sun), Perl o Python.

GTK ha sido portada a Windows pero el look-and-feel no es nativo.

Qt es una biblioteca multiplataforma para desarrollar interfaces gráficas de usuario. Fue creada por la compañía noruega Trolltech. Qt es utilizada en KDE, un entorno de escritorio para sistemas como GNU/Linux o FreeBSD, entre otros. Utiliza el lenguaje de programación C++ de forma nativa y además existen bindings para C, Python (PyQt), Java (Qt Jambi), Perl (PerlQt) y Ruby (QtRuby) entre otros. El API de la biblioteca cuenta con métodos para acceder a bases de datos mediante SQL, así­ como uso de XML y una multitud de otros para el manejo de ficheros, además de estructuras de datos tradicionales. Inicialmente Qt apareció como biblioteca desarrollada por Trolltech (en aquel momento “Quasar Technologies”) en 1992 siguiendo un desarrollo basado en el código abierto, pero no libre. Se usó activamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable éxito y rápida expansión.

Qt cuenta actualmente con un sistema de doble licencia: una GPL para el desarrollo de software de código abierto (open source) y software libre, y otra de pago para el desarrollo de aplicaciones comerciales. Las librerí­as Qt son también liberadas bajo licencia GPL para Windows y Mac.

wxWidgets son unas bibliotecas multiplataforma, freeware/Open Source para el desarrollo de interfaces gráficas programadas en lenguaje C++. Es una librería pequeña que encapsula en una interfase común llamadas al API nativo de cada sistema operativo.

wxWidgets usan una licencia GPL, concretamente la licencia L-GPL, similar a la GPL con la excepción de que el código binario producido por el usuario a partir de ellas, puede ser propietario, permitiendo desarrollar aplicaciones empresariales sin coste.

Las WxWidgets proporcionan una interfaz gráfica basada en las bibliotecas ya existentes en el sistema (nativas), con lo que se integran de forma óptima y resultan muy portables entre distintos sistemas operativos. Están disponibles para Windows, MacOS, UNIX/Linux, OpenVMS y OS/2. También pueden ser utilizadas desde otros lenguajes de programación, aparte del C++: Java, Javascript, Perl, Python, Smalltalk, Ruby

Generación automática de código

Conforme va madurando el campo de tecnologí­a de información, se van estableciendo patrones de referencia de cómo deben ser las aplicaciones de negocio y va aumentando la presión para tener ciclos de desarrollo cortos.

Surge entonces la necesidad de mecanizar el proceso de producción de software, y además hacerlo de manera flexible y ágil que permita incorporar la parte variable de manera robusta.

Un enfoque es desarrollo Cut-and-Paste usando programadores experimentados en el desarrollo de aplicaciones similares a la que se esta haciendo. Este modelo tiene sus limitaciones y no es realmente escalable. Por un lado es propenso a errores y consume horas-hombre que serian mejor empleadas en actividades que se beneficien de la capacidad creativa y visión del desarrollador. Por otro lado, realmente no permite de manera natural institucionalizar y transferir experiencias entre desarrolladores y entre grupos de desarrolladores.

En el ciclo de vida y desarrollo de una aplicación se requieren distintas perspectivas y niveles de abstracción. En un proceso mecanizado de desarrollo debe haber herramientas que idealmente nos permita partir de la conceptualización de las necesidades de negocio y de manera automática llegar a la implantación bajo tecnologí­as especí­ficas.

El grupo de patrones y prácticas de Microsoft ha desarrollado el concepto de fábricas de software como paquetes de referencia que incluyen una serie de artefactos que permiten mecanizar el desarrollo de familias de aplicaciones. Estos artefactos incluyen modelos, marcos (frameworks) y herramientas.

UML se utiliza en algunas herramientas que generan código a partir de un diagrama de clases por ejemplo. De manera más general el Object managment Group (OMG) ha desarrollado el concepto de arquitectura dirigida por modelos (model-driven architecture, MDA). Este enfoque pudiera ser a un nivel de abstracción y generalización demasiado alto para ser de uso practico.

MDA enfatiza independencia de plataforma. En la práctica, esto no puede ser un absoluto. Las caracterí­sticas de una tecnología o implementación son restricciones en el modelo.

MDA asume que están disponibles modelos para cualquier artefacto.

MDA utiliza UML como lenguaje de uso general. Algunas tecnologías y aplicaciones no se prestan para ser representados en UML y se pueden describir mejor con herramientas especí­ficas que permitan una mayor fidelidad al pasar de concepto a implementación.

MDA asume que 3 tipos de modelo son suficientes:

computation-independent model,

platform-independent model,

platform-specific model.

MDA se enfoca en transformaciones. Es difí­cil lograr un proceso completamente automático que vaya de concepto a implementación. La metodología debe incluir el manejo de la parte variable que no se puede automatizar y los cambos que se requieran durante el mantenimiento de una aplicación

Un lenguaje de modelación de uso general como UML esta diseñado para soportar el desarrollo de modelos que sirvan principalmente como documentación. Estos lenguajes pueden describir cualquier dominio, pero necesariamente de manera imprecisa por el alto nivel de abstracción que utilizan. En el caso de UML, las abstracciones genéricas se definen utilizando lenguaje natural informal.

Un lenguaje de domino especifico (DSL), esta diseñado para describir con precisión una tarea especifica. En vez de abstracciones genéricas utiliza conceptos tomados directamente de la tarea a modelar.

El concepto de fabricas de software de Microsoft utiliza como componente básicos leguajes de alta fidelidad como XML, C# y SQL, lenguajes de domino especifico (Domain Specific Language, DSL), scripts de flujos de trabajo (workflow), archivos WSDL, archivos DDL, SQL.

Las fábricas de software son especí­ficas a subsistemas como administración de clientes, administración de catálogos, cumplimiento de órdenes.

El machote (template) de una fábrica de software incluye código y metadata que se pueden cargar en un IDE o en una herramienta de desarrollo de aplicaciones empresariales. El concepto de machote es similar al de un machote de un documento de Word o Excel.

El uso de una fábrica de software incluye los siguientes pasos:

  • Análisis de problema. Primero determinar si el producto cae dentro del alcance de la fábrica de software.
  • Especificación del producto. Definir los requerimientos del producto en términos de sus diferencias con los requerimientos de los componentes de la fábrica de software.
  • Arquitecta del producto. Ajustar la fabrica de software a las características particulares del producto.
  • Implementación. Las actividades usuales de pruebas unitarias, pruebas de ejecución, ensamblaje de componentes, desarrollo de componentes
  • Instalación. Crear o re usar restricciones, configuración de infraestructura, validaciones, instalación de requerimientos y ejecutalbes.
  • Pruebas. Crear o re usar recursos de pruebas, datos de prueba, scripts de prueba, uso de herramientas de medición.

Las fábricas de software proporcionan un enfoque robusto a la creación de software usando un paradigma de modelación visual, pero va más allá del uso de modelos como documentación. Usando DSL y XML permiten usar metadata para automatizar la generación de código. Los cuatro pilares de las fábricas de software son: Líneas de software, marcos arquitectónicos (architecture frameworks), desarrollo dirigido por modelos, y guías contextuales

El esquema de fábrica de software es un modelo diseñado para soportar cómputo. El esquema de una fábrica es un árbol. Cada nodo en el árbol se conoce como una perspectiva (viewpoint). La perspectiva raíz corresponde a construir todo el entregable. Las perspectivas subyacentes se derivan por descomposición. Cada perspectiva describe la solución en términos de actividades a realizar y una explicación como realizar cada actividad. Las actividades se describen en términos de los productos que generan. Esto productos son los componentes que se utilizan para construir el entregable. Además cada perspectiva incluye recursos suministrados por la fábrica para resolver los problemas del dominio, generalmente automatizando total o parcialmente la tarea.

Par construir una fabrica se empieza sencillo con recursos simples y se va invirtiendo tiempo en desarrollar recursos más sofisticados conforme se va ganando experiencia en el dominio.


Bare-Naked Languages or What Not to Model

CodeGen’ing a Data Access Layer with CodeSmith


Microsoft DSL

CodeSmith Community: .netTiers

Sean Mccormack’s Codus

Software Factories

Wilson OR Mapper templates for CodeSmith

Can you code gen everything?

CodeSmith Community: Rocky CSLA Templates

Deklarit Kathleen Dollard

CodeSmith Community: Files

Andres Aguiar’s Blog

Eric Smith’s Blog

.nettiers demo/tutorial DAL in 15 mins

Global Bank Scenario

Visual Studio 2005 SDK Version 4.0

Jack Greenfield’s Blog

Code Generation Network

TypeBuilderLib, a Library to Build Dynamic Types Easily


Apple has been ordered to pay damages to rival Samsung Electronics by a court in the Netherlands.

The court said that Apple had infringed a patent held by Samsung relating to the way phones and tablet PCs connect to the internet.

Apple, which recently became the world’s most valuable firm, has been facing various legal issues.

In a separate case, it was fined $2.3m (£1.5m) in Australia for its claims on 4G capabilities of the iPad.

And it is still not clear how much it may have to pay to Samsung in damages.

The Dutch court did not specify any amount, but the damages will be calculated based on sales of Apple’s iPhone and iPad in the Netherlands.

“Samsung welcomes the court’s ruling, which reaffirmed Apple’s free-riding of our technological innovation,” the South Korean manufacturer said in an emailed statement to the BBC.

“In accordance with the ruling, we will seek adequate compensation for the damages Apple and its products have caused.”

Samsung had claimed that Apple had infringed four of its patents. However, the Dutch court said that only one of those had been breached.

Windows 8

Seattle.- A medida que Microsoft Corp se prepara para demostrar al mundo lo que su nuevo Windows 8 puede hacer para la próxima generación de tabletas de alta potencia, las revisiones iniciales del nuevo sistema operativo en el hardware existente resaltan los desafíos que enfrenta la compañía con el nuevo diseño radical de su producto insignia.

La mayor compañía de software del mundo dice que millones de personas ya están utilizando una versión preliminar que descargaron de Windows 8 en sus Pcs, laptos y dispositivos táctiles antes de su introducción oficial este otoño boreal.

En un evento mediático en Los Angeles el lunes, la compañía tiene previsto discutir sus planes de superar al iPad de Apple Inc esta temporada de compras de fin de año.

Hasta el momento, la mayor parte de los críticos han elogiado el aspecto de estilo amigable táctil “Metro” de Windows 8, que está basado en coloridos cuadrados, o mosaicos, que representan aplicaciones como correo electrónico y actualizaciones en tiempo real. Pero también han resaltado lo difícil que será para los usuarios alejarse de lo que ya conocen y confían.

Es como una cierta lucha para la gente que está deliberadamente orientada a una PC, que está acostumbrada al mouse”, dijo el ex estratega de Microsoft Al Hilwa.

Hilwa, ahora un analista en la empresa de investigación tecnológica IDC, ha estado probando durante dos semanas la última muestra de la versión. “Sin la pantalla táctil, luchaba con un mouse para hacer ciertas cosas”, dijo.

La nueva interfaz Metro solo ejecuta programas diseñados para ella, por lo que los usuarios deben volver a sus tradicionales computadoras de escritorio para realizar ciertas tareas, tales como escuchar música en iTunes de Apple.

“Lo que realmente me enfurece es que las aplicaciones Metro y las aplicaciones que se ejecutan en las computadoras de escritorio no están al tanto de la existencia de la otra”, dijo el analista de Forrester Research David Johnson. “No existe una forma fácil de navegar entre ellas, no estoy muy seguro a qué se debe”.

La última versión de la prueba del software aún no está concluida. Y aparte de unos pocos examinadores de la industria, nadie ha probado a Windows 8 en una tableta impulsada por los ultra eficientes chips de ARM Holdings, que es lo más cerca que Microsoft se aproximará para desafiar al iPad.

Microsoft debe ofrecer más detalles el lunes, y existen rumores de que podría introducir una tableta con su propia marca. La compañía se negó a hacer comentarios respecto a la reacción al nuevo sistema y sobre sus planes para el evento del lunes.

No obstante, Microsoft no ha logrado convencer aún a algunos de sus usuarios más leales.

“En este momento, no me han comprado”, dijo el analista Michael Cherry de Directions on Microsoft, una empresa de investigación independiente que se enfoca en el gigante tecnológico.

Cherry dijo que había insistido con Windows 8 durante algunos días, pero que tuvo problemas para configurar el correo electrónico en su máquina de prueba.

“No puedo confiar en ella como una herramienta de producción”, dijo. “Aún no me puedo cambiar. Para este momento, debería haber sido capaz de dejar atrás a Windows 7”.

Cherry, un ex gerente de programas de Microsoft, dice que le preocupa que la complejidad inicial del nuevo sistema le impida ser un éxito inmediato, como su predecesor, Windows 7.

“Si una persona que ha utilizado Windows a partir de Windows 1.0 no lo puede entender, entonces imagino que hay otras personas ahí afuera que no lo podrán entender”, dijo. “No veremos las largas filas en las tiendas Best Buy a medianoche. Me encantaría ver eso, pero simplemente no sucederá”.

Los principales críticos tecnológicos como Walt Mossberg de Wall Street Journal o David Pogue del New York Times no han expresado aún su opinión respecto al tercer y último “anticipo” de Windows 8, disponible libremente en internet el 31 de mayo.

El puñado de comentarios en los blogs centrados en tecnología en general elogiaron el nuevo aspecto de Windows 8, pero prácticamente cada uno ha resaltado lo difícil que será para los usuarios hacer el cambio.

“No podría dar a mi madre -que tiene 76 años- Windows 8 y esperar que sea productiva con el sistema”, dijo Johnson de Forrester. “Pero tampoco estoy seguro de que alguien de 30, o incluso 20 años, no se confundirá inicialmente con la interfaz de Metro”.

Los consumidores individuales y potenciales compradores del iPad, más que clientes corporativos, son el objetivo principal de Windows 8. Muchas grandes compañías se encuentran aún en el proceso de gastar millones de dólares para cambiarse a Windows 7.


.NET Compact Framework 2.0 es un repositorio de información y código fuente sobre Microsoft .NET Compact Framework. empezó como un proyecto de código abierto para extender la funcionalidad de .Net 1.x. A partir del Smart Device Framework 2.0 el código fuente dejo de ser libre.

En el mismo sito de Microsoft hay referencias a ejemplos de aplicaciones móviles que usan las extensiones de OpenNETCF.

El articulo Building a Wi-Fi Discovery Application with the .NET Compact Framework 2.0 explica a detalle una aplicación que usa estas librerías e incluye código fuente. Es un buen ejemplo para empezar a ver el ciclo complete de una aplicación móvil no trivial.

La solución de muestra incluye dos proyectos. La aplicación en si, y el código fuente OpenNETCF referenciado en la misma. Al construir la solución en Visual Studio 2005 se marcan warnings pero los proyectos se construyen con éxito. Se puede probar la aplicación en una Pocket PC 2003. Si la tarjetea de WiFi esta desactivada la aplicación genera una excepción. No es una aplicación de grado comercial pero es una buena referencia de lo que se puede hacer.

El articulo Deploying .NET Compact Framework 2.0 Applications with .cab and .msi Files continua con este ejemplo y explica como hacer un proyecto de instalación.

En un proyecto para aplicaciones inteligentes, cada archivo se marca con una acción de generación que se define en la ventana Propiedades del modo siguiente:

  • Un archivo marcado como Compile, valor predeterminado para todos los archivos y formularios de código, compilará los archivos en el ensamblado resultante.
  • Un archivo marcado como Content permite el empaquetado del archivo en el archivo .cab y su implementación en el proyecto. Asimismo, resulta útil para la implementación de archivos de configuración XML y bases de datos SQL Server CE.
  • Un archivo marcado como None simplemente se ignora. Esta acción resulta útil para incluir documentación en el proyecto, como diagramas de Visio que no se deben implementar.
  • Un archivo marcado como Embedded Resource se incluye en el ensamblado ejecutable como un recurso. Esta acción permite que el código escrito extraiga el recurso mediante programación. Asimismo, resulta eficaz para empaquetar imágenes y archivos de secuencias de comandos que se pueden utilizar posteriormente en la aplicación.

Antes de pasar a construir la aplicación para dispositivos inteligentes y crear los archivos .cab para la implementación, no se debe olvidar cambiar el modo de generación del proyecto de depuración a liberación. Esto reducirá el tamaño del ejecutable en el dispositivo (hecho importante en el caso de los dispositivos inteligentes de almacenamiento restringido) y aumentará la velocidad de ejecución.

Para hacer un proyecto de instalación automatica es necesario efectuar los siguientes pasos:

1. Crear archivos .cab para cada dispositivo donde va a correr la aplicación. Un .cab de instalación puede contener un archivo setup.dll con código no administrado, y por eso se requiere un .cab diferente para cada familia de procesadores. Si la aplicación no requiere de este archivo, entonces un solo .cab es suficiente.

2. Agregar los archivos y entradas de registro de la aplicación a los .cab

3. Proveer el código de acciones especiales a ejecutar durante la instalación y desinstalación de la aplicación.

4. Registrar la aplicación con ActiveSync para que se pueda instalar de la PC de escritorio a la Pocket PC.

5. Empacar todo en un archivo .msi

El primer paso es agregar un proyecto
Other Project types->Setup and deployment->Smart Device Cab Project
a la solución.

Al construir el proyecto se generan 3 archivos un .cab, un .log, y un .inf. El archivo .inf tiene parámetros de instalación que serán usados por ActiveSync.

El .cab es suficiente para instalar una aplicación en la Pocket PC pero es posible agregar un proyecto de instalación de escritorio para simplificar el proceso para el usuario.

Para aplicaciones móviles, hay dos cosas que el instalador debe hacer. Debe presentarle al usuario las pantallas del asistente de instalación en la PC de escritorio y debe instalar la aplicación en la Pocket PC.

La instalación en el Pocket PC se hace a través una aplicación llamada CeAppMgr.exe que es parte de ActiveSync. CeAppMgr.exe requires un archivo .ini que se debe agregar manualmente. En nuestro caso el .ini contiene lo siguiente:

Version = 1.0
Component = OpenNETCF WiFiDiscovery

[OpenNETCF WiFiDiscovery]
Description = Sample WiFi Network Discovery Application using the SDF
CabFiles =

Para activar el modo de depuración de CeAppMgr.exe es necesario meterle mano al Registry. Para los valientes

[HKLMSoftwareMicrosoftWindows CE ServicesAppMgr]

Existen algunos requerimientos que, aunque no son estrictamente necesarios técnicamente, son prácticas establecidas y necesarias para certificación.

Aplicaciones registradas con CeAppMgr deben estar en un subfolder de ActiveSync por ejemplo. Estos requerimientos los maneja el instalador utilizando variables predefinidas de Windows para mayor flexibilidad y para facilitar localización del software en varios idiomas. Para ejecutar estas acciones se agrega una clase de instalación.

Agregamos un proyecto de librerí­a de Windows a la solución de Visual Studio. A este proyecto le agregamos la installer class. Esta clase soporta eventos relacionados con el proceso de instalación y permite definir acciones previas y posteriores al proceso de instalación y al de desinstalación. Por ejemplo,

public CustomInstaller()
this.BeforeInstall +=
new InstallEventHandler(CustomInstaller_BeforeInstall);
this.AfterInstall +=
new InstallEventHandler(CustomInstaller_AfterInstall);
this.BeforeUninstall +=
new InstallEventHandler(CustomInstaller_BeforeUninstall);

Es necesario definir constantes para usar dentro del código en términos de entradas en el Registry, bajo la llave HKLM.

De esta manera el código sigue siendo valido bajo distintos idiomas y versiones de Windows.

private const string CEAPPMGR_PATH =
@”SOFTWAREMicrosoftWindowsCurrentVersionApp PathsCEAPPMGR.EXE”;
private const string ACTIVESYNC_INSTALL_PATH =
@”SOFTWAREMicrosoftWindows CE Services”;
private const string INSTALLED_DIR = “InstalledDir”;
private const string CEAPPMGR_EXE_FILE = @”CEAPPMGR.EXE”;
private const string CEAPPMGR_INI_FILE = @”WiFiDiscovery.ini”;
private const string APP_SUBDIR = @”OpenNETCF WiFiDiscovery”;
private string TEMP_PATH =
Environment.SystemDirectory + @”TEMPWiFiDiscovery”;

El ultimo paso es crear el proyecto de instalación.

Other project types ->Setup and deployment->Setup project

Despues de crear el proyecto, realizamos las siguientes acciones:

1. Cambiar el nombre del archivo de salida.

2. Indicar la ubicación de un directorio para guardar archivos temporales. Este direcorio debe estar ubicado de acuerdo a lo que definimos en la clase de instalación.

3. Definir las propiedades del proyecto como compañí­a, nombre de aplicación, etc.

4. Agregar los archivos de salida del proyecto CAB

5. Agregar en la carpeta de aplicación la salida de la clase de instalación

6. Agregar Custom Action usando la clase de instalación

7. Agregar archivo .ini

8. Construir todos los proyectos en la solución

9. Probar el instalador

Para mayor detalle se pueden consultar los articulos originales en el sitio de Microsoft.

El articulo Developing and Deploying Pocket PC Setup Applications aunque obsoleto tiene información complementaria y discute el caso .Net 1.x

Antes de poder ejecutar la aplicación, es preciso instalar .NET Compact Framework en el dispositivo. Si la aplicación requiere SQL Server CE, también será necesario instalar el archivo .cab adecuado. Aunque ambos se instalan automáticamente al implementar la aplicación desde Visual Studio .NET mediante el menú Implementar o al depurar el dispositivo, en producción será necesario emplear un mecanismo diferente.

Como se mencionó anteriormente, los archivos .cab creados para un proyecto no incluyen los archivos .cab correspondientes a .NET Compact Framework o SQL Server CE. Aunque Pocket PC 2003, y dispositivos posteriores, suelen incluir .NET Compact Framework en ROM, será preciso agregar los archivos .cab específicos de la plataforma en cuestión en el caso en que dichos dispositivos no los incluyan. Un modo sencillo de llevar a cabo esta operación para .NET Compact Framework es descargar y ejecutar el redistribuible.


Patrones de implementación para Microsoft .NET Compact Framework

Generación de código


Así­ como los objetos fí­sicos se mueven a través del tiempo y el espacio, las aplicaciones de software se mueven por diferentes ejes en su ciclo de vida. Concretamente, el mantenimiento de una aplicación requerirá de una serie de adecuaciones y cambios por distintos motivos: cambio de plataforma, cambios en el proceso de negocio, nuevos requerimientos, nueva base de datos. Etcétera. Además, desde el punto de vista del desarrollador, lo ideal es poder reutilizar lo más posible de esfuerzos anteriores. En el ciclo de vida de un sistema, más del 60% del costo es el mantenimiento

La tendencia a requerimientos cada vez más complejos con tiempos de desarrollo cada vez más cortos vuelve el re-uso de código un imperativo.

Teóricamente, la programación orientada a objetos facilita el re uso de código. Los atributos de los lenguajes orientados a objetos que promueven el re-uso de código son:

Abstracción de datos que promueve sistemas modulares.

Herencia que permite que las subclases re-usen código de las superclases.

Poliformismo facilita el re-uso de comportamiento bajo diferentes contextos.

Marcos (frameworks) que son conjuntos de clases abstractas que solucionan familias de problemas relacionados.

Pero, para que se cumpla esta promesa divina de re-uso, el código, o más bien dicho, el diseño, debe ser bueno, muy bueno. ¿Qué es, entonces, un buen diseño? Cada cuál tendrá su idea. A manera de contrapunto empecemos por lo negativo, ¿Qué características tiene un mal diseño? Concediendo que la aplicación cumple con los requerimientos para los que fue diseñada, un diseño puede adolecer de lo siguiente:

Rigidez. La aplicación es difí­cil de cambiar porque cualquier cambio afecta demasiadas cosas.

Fragilidad. Cuando se hace un cambio, la aplicación deja de funcionar en lugares inesperados.

Inmovilidad. Es difí­cil utilizar la aplicación como parte de otra aplicación porque las dependencias con el contexto están enmadejadas en el código.

¿Qué es lo que hace un diseño rí­gido, frágil, e inmóvil? Las interdependencias de sus módulos. Entonces, para que el proceso de mantenimiento no sea la imagen de un perro persiguiendo su cola, se debe tener cuidado de minimizar interdependencias.

Desde el punto de vista de la programación estructurada, un diseño se puede ir construyendo bottom-up o top-down. Es decir, a partir de los componentes o módulos que tengo disponibles voy construyendo módulos más complejos, hasta cubrir los requerimientos, o conversamente, voy dividiendo mis requerimientos entre sub-módulos, hasta que llego a un punto suficientemente concreto para resolverlo de manera independiente. Al final, de manera iterativa, se llega a un diseño de capas jerárquico, donde en un sentido estricto, los únicos componentes que pueden ser completamente independientes del resto son los módulos de más bajo nivel en la jerárquia, es decir los más concretos y especí­ficos, los más ligados al problema particular que se esta resolviendo.

La mecánica establecida para re-usar rutinas de bajo nivel es el uso de librerí­as. En la practica la productividad de un lenguaje o ambiente de desarrollo esta ligada con la calidad y disponibilidad de librerías. Esto esta bien, pero desde el punto de vista de re-uso de código las dependencias están al revés. Los módulos de alto nivel, que resuelven un proceso complejo de interacción entre la aplicación, sus módulos internos, y el contexto exterior son los que queremos re-usar. De acuerdo a este precepto, un buen diseño debe cumplir con el principio de inversión de dependencias.

El principio de inversión de dependencias

Módulos de alto nivel no deben depender en módulos de bajo nivel. Ambos deben depender de abstracciones.

Abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones.

Al concepto de inversión de control se le refiere como el principio de Hollywood:

Do not call us, we call you

Inversión de control es un aspecto clave que diferencia un marco orientado a objetos de una librería. Una librerí­a es un conjunto de funciones, tal vez organizadas dentro de clases, que una aplicación (cliente) llama dentro del código, la función hace lo que tiene que hacer, y regresa el control al cliente. En un marco orientado a objetos, es el marco el que llama al código del cliente. En .Net, por ejemplo, una manera de hacer esto es que el marco defina eventos a los cuales se subscribe el cliente y mediante el uso de delegados, el cliente asigna el compartimiento especifico que requiere.

En términos más generales, Interfaces es la manera de abstraer la interacción entre el cliente y el marco (framework). Una técnica de inversión de control es dependency injection.

La inversión de control es parte de lo que hace la programación de marcos orientados a objetos perturbadora para algunos. Al programar un procedimiento, la atención del programador esta en el flujo de control. Es difícil imaginar como se pudiera entender un programa sin saber la lógica de ejecución. Pero un buen marco abstrae el detalle del control de flujo. El foco de atención esta en los objetos, lo que puede ser al mismo tiempo más y menos tangible que el flujo de control.

En el marco, lo importante son las responsabilidades de cada objeto y la interacción (colaboración) entre ellos. Es una visión más abstracta, más declarativa del mundo, potencialmente más flexible y amplia que el enfoque en procedimientos.

Resumiendo, un buen diseño es aquel que nos permite hace cambios de manera no intrusiva, es decir, añadiendo código en vez de cambiando código. Un buen diseño se puede modificar sin tocar el código existente. O sea, en un desarrollo orientado a objetos el esfuerzo debe estar en el diseño. La programación orientada a objetos debe ser fácil, a costa de un proceso exhaustivo de diseño. He ahí la promesa y el reto fundamental de la orientación a objetos.

Los buenos patrones de diseño no se inventan, se descubren. Desde una perspectiva macro de diseño el principio de inversión de control es fundamental. Desde la perspectiva de las clases en si, ¿Qué principios se deben seguir para facilitar un buen diseño?, o más importante, ¿Qué debemos evitar para no inhibir el potencial del diseño? ¿Cómo garantizar que no haremos daño?

Algunos tips:

Es más fácil reusar un comportamiento agregando un componente que a través de herencia.

Eliminar análisis de casos. En el caso de .Net se pueden usar genéricos.

Reducir el número de argumentos. Sin embargo, al crear un objeto, es preferible exponer todas las dependencias para facilitar pruebas de clases individuales.

Reducir el tamaño de los métodos. El propósito del método debe ser obvio e idealmente el código debe ser auto documentado.

Las jerarquías de clases deben ser profundas y espigadas. Una clase todopoderosa, rodeada de ratoncitos indica un área de oportunidad en el diseño. Cada clase debe tener una responsabilidad principal, de preferencia única, claramente definida.

Minimizar acceso a variables. Una clase debe exponer solo aquello que sea estrictamente necesario para cumplir con su responsabilidad. En .Net se promueve el uso de propiedades en vez de variables públicas, para que la clase tenga mayor control en el uso de sus valores a través de métodos get y set.

La raíz de la jerarquía de clases debe ser abstracta. Es decir, no debe tener ningún (minimizar) detalle de implementación y solo exponer la interfaz de la clase.

Subclases deben ser especializaciones. Usualmente una subclase no debe redefinir métodos de la superclase, solo añadir nuevos.

Dividir clases grandes. Factorizar diferencias de implementación en sub-componentes. Separar métodos que no se comunican entre si.

Evitar el uso implícito de parámetros.

La guí­a del buen objeto,

  • Mantengo un estado consistente todo el tiempo.
  • No tengo métodos o variables estáticos.
  • Nunca espero o regreso null.
  • Fallo pronto.
  • Soy fácil de probar, todos los objetos de los que dependo los recibo como parámetros, normalmente durante construcción.
  • Los objetos de los que dependo pueden ser substituidos por Mock Objects (no uso dependencias a clases concretas).
  • Encadeno constructores multiples a un lugar comun, usando this
  • Siempre defino hashCode() junto a equals().
  • Prefiero valores inmutables que puede tirar fácilmente.
  • Tengo un valor especial para nada, por ejemplo EMPTY_SET para colecciones.
  • Disparo una excepción cuando el cliente pide algo que no es razonable, por ejemplo, abrir un archivo que no existe.
  • Disparo una excepción cuando no puedo hacer algo que deberí­a poder hacer, por ejemplo error de disco al leer un archivo abierto.
  • Solo atrapo excepciones que puedo manejar completamente.
  • Solo registró en bitácora información que alguien necesita ver.


Johnson and Foote’s paper Designing Reusable Classes, Journal of Object-Oriented Programming , 1988.

El libro del Gang of Four

Richard Sweet ,1983.

John Vlissides column for C++ report

One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user’s application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.

Ralph Johnson y Brian Foote

Comparación de Java y C#

Hace algunos años , en un lugar de cuyo nombre no quiero acordarme, se discutía el plan quinquenal del programa académicos en tecnologí­a de información. Los administradores del grupo, siguiendo linea del jefe divisional, decidieron normalizar el uso de Java para toda la curricula departamental. Algunos de los profesores expresamos tibias dudas sobre al asunto, pero no hubo realmente opiniones en contra.

A mi el incidente me recordó la tendencia histórica de los ejércitos del mundo a preparase para la guerra anterior sin comprender que el entorno tecnológico y social hacen inoperantes e irrelevantes enfoques que en el pasado hubieran sido determinativos e innovadores. La linea Magniot de los francés como ejemplo concreto.

Aunque Microsoft es más fiero como monopolio que como motor tecnológico, tiene el suficiente peso económico y social para absorber el mejor talento del mundo y el Sr. Puertas ha mostrado saber a donde va el puck.

Java sigue teniendo su lugar como herramienta de desarrollo inter-plataforma pero hay evidencias de que su mejor momento tal vez ya paso. Microsoft tiró el guante blanco al implementar la aplicación de referencia J2EE, PetShop, en .Net y obtuvo mejores números, tanto en lineas de código como en rendimiento. Cada vez que Java levantaba el guante, la evidencia era más contundente: .Net permite desarrollos en menos tiempo y con mejor rendimiento que J2EE.

En el mismo foro de desarrolladores de Java de Sun el consenso en el tema de manejo de genéricos fue que la implementación de C# es superior a la de Java.

Aunque hay diferencias de implementación, Java y C#, tienen puntos en común. Despues de todo, C# es la respuesta de Microsoft a Java. El articulo C# and Java: Comparing Programming Languages presenta una comparación detallada.

Un punto en común entre Java y C# es que no manejan herencia multiple y promueven el uso de interfaces para propositos equivalentes.

El sitio Desarrollo Profesional de Aplicaciones tiene bastante material didactico sobre .Net en español.