Archive for February 4, 2010

04 Feb 2010
development

Eliminando directorios de Subversion (.svn) desde la línea de comandos

Subversion es un excelente sistema de control de versiones centralizado (VCS) de código abierto ampliamente utilizado alrededor del mundo no sólo por los desarrolladores sino también por diversas personas que lo usan para mantener un control de cambios en sus documentos varios.

Es común para un usuario de Subversion utilizar el famoso cliente TortoiseSVN para manejar sus directorios de trabajo actuales conectados a un repositorio de Subversion. Como algunos se habran percatado, Subversion crea directorios “ocultos” .svn donde contiene la metadata necesara para trabajar de forma desconectada al repositorio, a veces estos directorios pueden llegar a ser un poco “irritantes” y necesitamos deshacernos de ellos. Recientemente un amigo me llamó con el siguiente problema:

Tengo un problema, el repositorio original no existe, por lo tanto no puedo hacer el “export” de TortoiseSVN de mi repositorio para deshacerme de los directorios .svn, necesito enviarle el código fuente a un cliente pero no quiero enviarle los .svn, ¿cómo hago para deshacerme de ellos? la estructura de directorios es muy compleja por lo que navegar uno a uno y quitarlos es un poco tedioso.

Es ahí cuando sale a la luz nuestro viejo amigo la línea de comando, no es nada que un simple script de Cmd o PowerShell en Windows no pueda resolver. Comencemos con el viejo y ya casi obsoleto Cmd:

for /r %%f in (.svn) do rd /s /q "%%f"

En PowerShell es un poco más complejo, pero igual se puede lograr :) 

get-childitem -Include .svn -Recurse -force | Remove-Item -Force –Recurse

Obviamente, cualquiera de los dos comandos deben correrse en el directorio que queremos limpiar.

Saludos!

UPDATE: mi amigo jfroma me sugiere el uso de SVN Export para lograr lo mismo, bueno, recordemos que SVN Export es una operación conectada de Subversion, eso indica que debemos tener conexión al repositorio para efectuarla. Como expongo en mi caso, mi amigo no tiene acceso al repositorio original (para ser exacto según me contó fue borrado), he ahí porqué no podemos usar Export y debemos recurrir a otras “técnicas” tibetanas para lograrlo.

cristian | 3 comments | Tags: , , , ,
03 Feb 2010
development

Windows Workflow InvokeWebService Activity and Client Credentials

En los últimos meses he estado ya más que aburrido en Microsoft Workflow Foundation, una relativamente impresionante framework de creación de flujos de trabajo de forma declarativa (o por lo menos así lo mencionan teóricamente, luego conversamos más de esto). Hoy mi cliente me menciona que uno de sus workflows no funciona, si, así de descriptivo…

Revisando el tracelog del proceso me doy cuenta que simplemente se debe a que dentro del Workflow existe una InvokeWebService Activity, yep, esta es una actividad de Workflow Foundation 3.0 diseñada para consumir viejos servicios ASMX.

Como recordaremos nuestro viejo ASMX no soporta configurar cosas como credenciales desde el archivo de configuración (como lo soporta WCF obviamente) y esto puede hacerse fácilmente desde código, el problema es que a “simple vista” nuestra InvokeWebService Activity no presenta una forma de cambiar las credenciales, es cuando un poco de lectura en MSDN nos ayuda enormemente :)

Bien, si bien no podemos “settear” las credenciales de un webservice directamente en el designer, lo podemos hacer en “código” antes que el servicio sea invocado, eso lo logramos con un handler al evento Invoking

Lo demás es simple manejo de credenciales en ASMX webservices.

// C# Code: Dentro del codebehind del workflow
protected void InvokeWebService_Invoking(Object sender, InvokeWebServiceEventArgs e) {
    var proxy = e.WebServiceProxy as MyWebServiceDefinition;
    if (proxy == null) return;
    proxy.ClientCrendetials =
        new System.Net.NetworkCredential("usuario", "password");
}
' VB Code
Public Sub InvokeWebService_Invoking(e As InvokeWebServiceEventArgs)
    Dim proxy = CType(e.WebServiceProxy, MyWebServiceDefinition)
    If proxy IsNot Nothing Then
        proxy.Credentials = New System.Net.NetworkCredentials("usuario", "password")
    End If
End Sub

Ojo con las definiciones anteriores, WebServiceProxy retorna tipo Object, por lo que hay que castearlo al tipo del webservice en específico.

Suficiente Workflow Foundation por hoy… Por cierto, les interesa el tema? ¿les gustaría más de WF en el futuro?

Saludos!

cristian | 6 comments | Tags: ,