Interesante nota de Peter Bromberg en la cual menciona desde su punto de vista cuales son los 10 FrameWorks que deberíamos revisar durante lo que queda de año 2007 para no “quedarnos obsoletos”. Ciertamente, cada uno podemos tener nuestra propia interpretación, pero no está menos ver cual es revisar otros puntos de vista.

El listado incluye las siguientes tecnologías:

1. WCF (Windows Communication Foundation)
2. ADO.NET (and LINQ)
3. WPF (Windows Presentation Foundation)
4. SQL Server 2005 (and on)
5. ASP.NET 2.0
6. Security
7. TDD (Test Driven Development)
8. Networking (System.Net and related)
9. Threading
10. Learning

Enlaces:
Top 10 .NET Framework Technologies to Learn in 2007

Compártelo

A pesar de que la continuidad de J# está mas que cuestionada, todavía puede ser útil para varias cosas entre ellas comprimir archivos.

Desarrollando una aplicación Web en .Net hemos tenido la necesidad de comprimir varios archivos en un fichero Zip y enviarlos al cliente Web de forma transparente para el usuario.

Existen numerosas librerías para trabajar con ficheros Zip, pero encontramos una forma sencilla de trabajar con los ficheros Zip desde un programa VB.Net (también válido para C#). El Framework 1.1 de Microsoft (y también el 2.0) incorporan el lenguaje J# que es un “pariente de Java”, luego “java.util.zip” debe existir en algún lado. Si alguien se pregunta si existe en C# la respuesta es no
Efectivamente J# contiene “java.util.zip” y está dentro de “vjslib.dll”. Primero, nos aseguramos que tenemos en nuestro servidor/pc está librería, sino la tenéis podéis descargaros el “Paquete redistribuible de Microsoft Visual J# .NET versión 1.1” (o en inglés “Microsoft Visual J# .NET Version 1.1 Redistributable Package”) en esta dirección.

Añadiendo una referencia a la librería vjslib.dll en nuestro proyecto ya podemos utilizar las funciones que necesitamos para acceder a los ficheros zip como en el siguiente ejemplo:


Imports java.util
Imports java.util.zip
Imports java.io

Public Function createZip(ByVal zipPath As String, _
  ByVal files2Zip As System.Collections.ArrayList) _
  As Boolean  
  Dim zipOutputStream As zipOutputStream
  Dim zipEntry As zipEntry
  Dim fileInputStream As java.io.FileInputStream
  Dim file2Zip As String
  Dim auxObj As Object   ‘ Esta variable contiene el valor que la
  ‘ función retornara
  Dim created = True Try
  ‘ Crea el fichero zip
  zipOutputStream = New _
    zipOutputStream(New _
    java.io.FileOutputStream(zipPath))
  If Not files2Zip Is Nothing Then
    For Each auxObj In files2Zip
      file2Zip = CType(auxObj, String)
      zipEntry = New _
      zipEntry(System.IO.Path.GetFileName(file2Zip))
      ‘ Comprimimos los datos
      zipEntry.setMethod(zipEntry.DEFLATED)
      ‘ Añadimos el fichero al zip
      zipOutputStream.putNextEntry(zipEntry)
      Try
        fileInputStream = New _
          java.io.FileInputStream (file2Zip)
        Try
          CopyStream(fileInputStream, _
          zipOutputStream)
        Finally
          fileInputStream.close()
        End Try
      Catch e As Exception
        created = False
      Finally
        zipOutputStream.closeEntry()
      End Try
    Next
  End If
Catch e As Exception
  created = False
Finally
  If Not zipOutputStream Is Nothing Then
    zipOutputStream.close()
  End If
End TryReturn created
End Function

Compártelo

Hay un curioso problema al intentar acceder a un Excel / Access en un servidor Web mediante OLEDB y ASP.NET. Es algo trivial, pero puede haceros perder mucho tiempo. El error se produce al llamar al método “Connection.Open” para abrir una connexion a un fichero Access o Excel con ASP.NET y OleDb. Hay dos posibles causas:

Primera causa: La cuenta ASP.NET/Impersonated no tiene suficientes permisos para crear el fichero ldb.

• Solución: Dar a la cuenta del usuario ASP.NET permisos de escritura/lectura a la carpeta donde está el fichero Excel/Access. Si estas utilizando “impersonation”, tienes que dar a la cuenta “impersonated” los permisos mencionados, es decir, a todos los usuarios que se vayan a conectar (con seguridad Windows).

Segunda causa: La cuenta “Impersonated” no tiene suficientes privilegios para crear los ficheros temporales.
Cuando  abres un fichero Excel o Access usando Jet, require la creación de ficheros temporales. Con ASP.NET estos ficheros temporales serán creados en el directorio:

“C:\Documents and Settings\<NombreServidor>\ASPNET\Local Settings\Temp”

Por defecto la cuenta del usuario ASP.NET tiene completo acceso a este directorio. Sin embargo, cuando estas usando “impersonation”, esta cuenta no tendrá acceso por defecto. En consecuencia, el proceso Jet no tendrá acceso a crear ficheros temporales cuando abre una conexión a un fichero Access o Excel con ASP.NET. Debido a esto, OleBd lanza una excepción sin un mensaje específico: “System.Data.OleDb.OleDbException: Error no especificado” o en inglés “System.Data.OleDb.OleDbException: Unspecified error”.

• Solución: Dar permisos totales a la cuenta de “impersonated” a la carpeta mencionada. No está demás mirar el artículo de Microsoft donde encontraréis mas detalles.

Compártelo

Aunque es relativamente sencillo con la tecnología .Net cambiar de un lenguaje de programación a otro, ya que la filosofía de trabajo es la misma, los objetos, los espacios de nombres…, pero al cambiar entre VB.Net y C# pueden resultar frustrantes determinadas características de cada uno de los lenguajes. Un ejemplo, son las palabras claves para los tipos de clases en VB.Net.

Os incluimos una tabla de equivalencias entre VB.Net y C# que os hará mas fácil el cambio de lenguaje o traducir código de los ejemplos que encontréis en Internet y que no estén en el lenguaje que utilizáis.

Lea el resto de esta entrada »

Compártelo

Cuando empiezas a programar en VB.Net después de haberlo hecho anteriormente en VB 6.0 (Basic script, WSH, VBA… etc.) aparentemente todo es lo mismo, pero mejor, un lenguaje mas coherente y mejor estructurado. Sin embargo, es cierto que hay cosas que hechas de menos, principalmente funciones que usabas y que ahora ya no valen porque han sido sustituidas por otras funciones.

Os presentamos algunas equivalencias de VB 6.0 que os ahorrarán tiempo a la hora de trabajar con cadenas de caracteres en VB.Net.

Comandos equivalents:

Len     >> miCadena.Length
Mid     >> miCadena.SubString(<inicio>,<longitud>)
Replace >> miCadena.Replace(<cadanaBuscada>,<cadenaNueva>)
InStr   >> miCadena.IndexOf(<cadenaBuscada>)
UCase   >> miCadena.ToUpper
LCase   >> miCadena.ToLower
Split   >> miCadena.Split(<delimitador>)
Join    >> String.Join(<delimitador>,<array>)
Trim    >> miCadena.Trim
LTrim   >> miCadena.TrimStart
RTrim   >> miCadena.TrimEnd
Compare >> String.Compare
Left    >> miCadena.SubString(<inicio>,<longitud>)
Right   >> miCadena.SubString(<inicio>,<longitud>)

Por ejemplo, para obtener la longitud de una cadena de texto llamada “miCadena” en VB 6.0 sería

Longitud = Len(miCadena)

Mientras que en VB.Net sería

Longitud = miCadena.Length

Existen algunas funciones para las que no existe una directa traducción y otras que son nuevas. Como las funciones “String$” o “StrReverse” de VB 6.0 o las funciones “PadLeft” o “EndsWith”.

La función “String$(<c>,<x>)” existente en VB 6.0 que permitía construir una cadena de caracteres a partir de la cadena “c” repetida “x” veces. Por otro lado, la función “StrReverse(<c>)” permitía dar la vuelta a una cadena de caracteres, nunca llegue a entender muy bien su sentido, pero ahí estaba en VB 6.0.

Finalmente, VB.Net incorpora algunas nuevas funciones como “PadLeft” y “PadRight” que insertan caracteres blancos para alinear las cadenas de caracteres a la izquierda o derecha. Las funciones “EndsWith” o
“StartsWith” permiten comparar de forma sencilla como termina o empieza una cadena de caracteres.

Compártelo