DoNet.QueIdeas

Bueno, para comenzar diremos que los estándares admitidos por .NET para los idiomas los podéis ver en la MSDN http://msdn.microsoft.com/es-es/library/system.globalization.cultureinfo(VS.80).aspx, deciros tambíen que la cultura en un WebForm se establece automáticamente por cada sesión de usuario que se inice en el web, dependiendo del idioma que esté configurado en el navegador del cliente.

Ahora nos surge el problema de forzar el idioma a escoger, bien porque nuestra página permite otros idiomas o bien por necesidad intrínseca del funcionamiento de nuestra página. Teniendo en cuenta los estándares mencionados arriba, podemos variar la cultura de nuestra página de la siguiente manera:

Thread.CurrentThread.CurrentCulture = New CultureInfo("es-ES")
Thread.CurrentThread.CurrentUICulture = New CultureInfo("es-ES")

Bien, explico un poco esto, en las lineas podemos ver que vamos a variar la cultura actual del sitio web y la cultura de la interfaz, esto se hace con CurrentCulture y CurrentUICulture, en primera instancia debemos de establecer la cultura principal del programa a través del hilo principal de ejecución del mismo, esto se hace cogiendo este hilo principal, Thread.CurrentThread, y estableciendo la cultura en ese instante.

Otro problema que nos encontramos es que en el momento de cambiar la cultura, podríamos establecer esta cultura en el hilo en el instante que nos apetezca, pero ocurre que la página Webform ya ha establecido su cultura previamente a nosotros cambiarla, ya que hay un procedimiento en un nivel superior de la jerarquia de clases de la Webform que ha hecho este trabajo y ha escogido el idioma previamente. Pues bien, para solventar este problema y que el cambio de idioma lo veamos reflejado en nuestra web en el momento del cambio, hay otra solución, sobrecargar el método “InitializeCulture” de la clase padre “System.Web.UI.Page” de nuestro WebForm, y ahí colocar el código del cambio de cultura, ya que este procedimiento es el que se encarga de inicializar la cultura de nuestra página antes de ser mostrada en el cliente. Esto quedaría así:

    Protected Overrides Sub InitializeCulture()
        Thread.CurrentThread.CurrentCulture = New CultureInfo("es-ES")
        Thread.CurrentThread.CurrentUICulture = New CultureInfo("es-ES")
    End Sub

Bueno, y esto abre a la imaginación tanto como os apetezca, por cierto en el valor “es-ES” se pueden poner todos los valores aceptados por este método descrito en la web de arriba. Así que ya podeís cambiar el idioma de vuestra web “cuando os apetezca” .

Saludos!

Bien, en este post voy a intentar explicar que es el CLR de NET Framework, para mí, y para mi opinión personal el CLR es una maquina virtual al mismo estilo que JVM para java, es la máquina virtual donde se ejecuta el bytecode de los ensambladores generados en .NET. Los compiladores de lenguajes .NET se encargan de compilar el código a bytecode MSIL (Microsoft Intermediate Languaje), que es el interpretado por el CLR.

El CLR compila por bloques el código MSIL en tiempo real, es decir, conforme se vayan usando las funcionalidades del ensamblado, el CLR generará un código nativo que es el que finalmente se ejecutará en la máquinal, así se intenta abstraer el código creado en la máquina bajo cualquiera de los lenguajes usados en .NET del código máquina.

CLR se divide por capas en su núcleo, para dar más interoperabilidad con el sistema y los desarrolladores. Estos son:
- Niveles de seguridad.
- Manejo de excepciones.
- Administración de hilos.
- Administración de memoria.
- Recolector de basura (GAC)

Destacar que a pesar que es una “maquina virtual” el CLR solo se ejecuta en entornos Windows.

Adjunto una pequeña imagen explicativa del CLR (Autor: Leif Arne Storset, Fuente: Wikipedia):

Es un post pequeño pero creo que explicativo a pequeños rasgos. Saludos!

Deciros que la nomenclatura using es muy útil usarla cuando usamos recursos que debemos liberar forzosamente (acceso a fichero, aperturas de registro en bd’s, manipulación de imágenes…etc) para no tener problemas despúes.

Como nomenclatura de visual studio es muy usada para el acceso a ficheros, pero es posible usarse con cualquier clase que implemente la interfaz IDisposable, asegurándonos que la clase usada en el estamento using liberará “SI o SI” (como dice un presidente de un club de futbol ) los recursos que esté usando, dé error en el bloque de código o no, ya que es el Garbage Collector del visual studio el que se encarga de llamar a el método dispose de la clase que implementa la interfaz.

Para este ejemplo usaremos el acceso a un fichero.

El ejemplo es sencillo, ya que lo único que debemos hacer es usar la nomenclatura de este modo:

Using fich As New FileStream("C:\pruebas.txt", FileMode.Open)
       'CODIGO A ESCRIBIR PARA MANEJAR EL FICHERO
End Using

De este modo nos estamos asegurando que  el fichero pruebas.txt será liberado cuando termine el bloque using, sin provocar problemas en posteriores accesos al fichero.

Hay casos, como por ejemplo, el acceso a datos que al declarar el bloque nos obliga a abrir dicha conexión dentro del bloque, con esto quiero decir, que no por crear el bloque using ya damos por hecho que el recurso se abre y se cerrará solo (esto último sí es cierto). Lo que damos por hecho es que en el caso del ejemplo anterior si se abrirá el archivo porque la clase FileStream en su constructor ya abre el recurso, pero en el caso de una conexion de datos el constructor de dicho conector de datos no abre la conexion en su constructor, con lo cual debemos abrirlo una vez asignado el recurso.

Ejemplo:

'ESTA DECLARACIÓN NO IMPLICA LA APERTURA DE LA CONEXIÓN SOLO LA INICIALIZACION DEL OBJETO
Using conn As New SqlConnection("CadenaConexion")
           conn.Open() 'Esto si nos asegura su apertura, ya el bloque using se encargará de liberarlo (cerrar la conexión)
          'CODIGO A ESCRIBIR
End Using

Resumiendo,

Lo que si nos aseguramos con un bloque using es la liberación de recursos, pero no la apertura de esos recursos, esto dependerá de la clase usada en el using.

Yo estuve un tiempo buscando como registrar una DLL en el COM para la interoperabilidad con ASP 3.0, PHP, etc.. bueno despues de buscar y buscar, investigar, romperme los ojos… etc… era más simple de lo que pensaba. Para poder registrar una dll en el COM de windows primero debemos definir la clase como visible desde el COM y definirle una key o firma del ensamblado. Se hace de la siguiente manera:

1.- Indicamos al proyecto que sea visible desde el COM.

2.- Creamos la key del proyecto.

Hay que tener en cuenta que a la hora de compilar el ensamblado debemos hacer funciones (procedimientos) que sean “entendibles” por cualquier lenguaje de programación no .net, esto es, usar si se puede, funciones, procedimientos, propiedades, etc.. que devuelvan tipos de datos nativos, así será más facil entender por ASP3.0 por ejemplo, php o cualquier otro. Si un momento dado tu ensamblado posee funciones no compatibles con COM el registro del COM avisará cuando se registre en la máquina (solo si necesita registro para aplicaciones no .NET). Si estos ensamblados se van a usar en .NET solo hay que añadirlos al assembly de windows, esto se hace:

1.- Abrimos una aplicacion consola desde el path de Visual Studio.

2.- Escribimos en la linea de comandos: gacutil -I RUTAENSAMBLADO (Ej. gacutil -I c:\midll.dll)

Si necesitamos interoperabilidad con COM hay que registrar el ensamblado en windows. Se hace: regasm /tlb /codebase RUTAENSAMBLADO (Ej. regasm /tlb /codebase c:\rutadll.dll)

Esto debe mostrarte un mensaje de finalización en ingles como que se ha procedido al registro correctamente, en el caso que hubiera alguna incompatibilidad (como hemos comentado antes) de tipos de datos no compatibles con COM, se verá como en este paso la aplicación regasm lo mostrará.

Bueno, después de escribir este tocho “como mi primr HOLA MUNDO” del blog. Espero que lo veáis util y hagamos de esto un blog con bastantes post para ayudar…. un saludo!!