This post is about a question that many developers ask themselves, ¿how can I get the SharePoint version programmatically?
There are at least three possible ways to do this (that I'm aware of):
In my case, I'm always using WMI and Windows provides us with the right tool (WBEMTEST.EXE) to try our WQL queries
Regards,
Angel
Este post trata de una pregunta que muchos desarrolladores se hacen, ¿cómo determino la versión de SharePoint que tengo instalada por medio de código?
A continuación enumero las tres posibles maneras (que yo conozco para hacerlo):
En mi caso particular, siempre hago uso de WMI y Windows nos ofrece WBEMTEST.EXE para probar nuestras consultas WQL
Saludos,
Angel
Writing code nowadays can be considered as a "cheerful experience", we have a complete set of tools and development environments that make us more productive, helping us in the delivery of high-quality software. 15 years ago it was a hard task to find IDEs with Intellisense support, we used to store our application settings in .INI files and we didn't even have any virtualization environment in order to perform tests before sending out our solution to the customers, that's why it's a new adventure each time we got engaged on a new development project and coding hasn't ever been as enjoyable as it is today. A few years ago I read a book written by Jeffrey Richter called "Advanced Windows" and I learned heaps from this book, as a matter of fact, last year I bought his latest book called "Windows via C/C++" which is a classic and a must have in every Windows developer toolbox, same thing occurs with Charles Petzold's book, however I learned a lot about Windows internal mechanisms by reading Richter's, for instance, how can processes exchange information between them? What's the difference between a Mutex and a Semaphore for threads synchronization? just to mention a few. Windows is a product that has evolved and grown throughout the years, despite of new APIs and functionality that have been included into it we will always need access to the PC's memory, for example we can mention Inter-Process Communication (IPC) and virtual memory access, this post is about it pretty much, how can I get access to the virtual memory so I can address and use a given amount of bytes? I think you know already what I'm talking about. Memory Mapped Files can be defined as "a segment of virtual memory which has been assigned a direct byte-for-byte correlation with some portion of a file or file-like resource. This resource is typically a file that is physically present on-disk, but can also be a device, shared memory object or other resource that the operating system can reference through a file descriptor". They have three main purposes which are:
-
Load and execute .exe files and DLLs
-
Access files on-disk very quickly without using buffers. Windows handles this for us
-
Allow many processes to share information in memory
The following diagram depicts some implementations for memory mapped files
Once the file is mapped in memory, a view based on that file needs to be created, I mean, a region or space within the file which allows a process to read and write onto it, when creating the view we specify bytes to be mapped, file offset and desired access, this process is shown in the image below
One of the new features bundled in .NET Framework 4.0 besides DLR (Dynamic Language Runtime), parallel processing and support for memory mapped files. The code that accompanies this post demonstrates how to do it using the new MemoryMappedFile class plus my own implementation with .NET 3.5, C# and a little of Interop.
Further reading about this topic can be found at Virtual Memory and Paging
Regards,
Angel
Format: swf
Duration: 22 min
Hoy en día es ameno “echar código”, pues tenemos herramientas de desarrollo que nos ayudan a ser productivos y aseguramos la calidad del software que hacemos. Hace 15 años atrás era difícil encontrar entornos de desarrollo con Intellisense, guardábamos nuestra configuración en archivos .INI y no disponíamos de virtualización para probar nuestra aplicación antes de enviarla al cliente, por eso en la actualidad cada día es una aventura y programar es más divertido. Hace unos años atrás leí un libro escrito por Jeffrey Richter titulado “Programación avanzada para Windows 95/NT”, aprendí mucho de ese libro de hecho el año pasado me compré la última edición del mismo titulado “Windows via C/C++”, es un clásico como el libro de Charles Petzold, sin embargo con el libro de Richter aprendí cosas sobre el funcionamiento interno del Sistema Operativo, por ejemplo, ¿cómo los procesos pueden intercambiar información entre sí?, ¿cuál es la diferencia entre un Mutex y un semáforo para sincronizar hilos? y muchas otras cosas más. Windows es un producto que ha madurado y crecido con el paso de los años, a pesar de nuevas APIs y funcionalidad siempre tendremos que tener acceso a la memoria del PC, un ejemplo de esto es la comunicación entre procesos (IPC) y el acceso a la memoria virtual, el siguiente post trata de eso, ¿cómo utilizar la memoria virtual para así direccionar y/o utilizar una cantidad de memoria que yo desee? Me imagino, ya saben a lo que me refiero y es Archivos mapeados en memoria (Memory Mapped Files) que lo podríamos definir como “un segmento de la memoria virtual la cual se le ha asignado una correlación directa byte a byte con alguna porción de un archivo ó algún otro recurso, el cuál típicamente es un archivo en disco pero también puede ser un dispositivo, un objeto compartido de memoria u otro recurso que el sistema operativo pueda referenciar a través de un descriptor de archivo”. Los archivos mapeados en memoria tienen tres propósitos los cuales son:
-
Cargar y ejecutar archivos .exe y bibliotecas de enlace dinámico (DLL)
-
Accesar archivos en disco rápidamente sin necesidad de usar búferes, Windows se encarga de esto por nosotros
-
Permitir a varios procesos compartir la misma información en memoria
El siguiente diagrama muestra alguna de las implementaciones para los archivos mapeados en memoria
Una vez que el archivo se encuentra mapeado en memoria, es necesario crear una vista basada en el mismo, es decir, una región ó espacio dentro del archivo a la cuál un proceso puede leer y escribir, al momento de crear la vista se especifica desde donde se va a comenzar a manipular el archivo así como el número de bytes a utilizar, este proceso lo podemos ver en la imagen mostrada a continuación
Una de las características nuevas que trae consigo el .NET Framework 4.0 además de DLR (Dynamic Language Runtime), procesamiento paralelo y muchas otras más, es el soporte para archivos mapeados en memoria, el código de este posting demuestra como hacerlo con la nueva clase MemoryMappedFile así como mi propia implementación con .NET 3.5, C# y un poco de Interop.
Si deseas leer un poco más sobre este tema puedes revisar estos links en Wikipedia: Memoria Virtual y Paginación de Memoria
Saludos,
Angel
Format: swf
Duration: 38 Min
Structured Exception Handling (SEH), it’s one of the top used features by developers, it’s not required any more to be dealing with On Error labels or any other less elegant mechanism to handle error conditions, however .NET Framework is an existing layer between our application and the operating system, even when the Exception class describes an error condition it doesn’t provide the error code and message associated to the operating system, that’s why it’s frustrating sometimes to interpret some “less-descriptive” exceptions and hence recovering any Windows error information can be of great help. Throughout the years Windows API has evolved and grown in size and error messages as well, many of these messages can be found in the SDK and WDK, so I had this idea about extending the Exception class by implementing an extension method. Extension methods enable us to “add” methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. They are a special kind of static method, but they are called as if they were instance methods on the extended type. The most common extension methods are the LINQ standard query operators that add query functionality to the existing IEnumerable and IEnumerable<T>.
To retrieve the description for a given error code we use the FormatMessage function, as it’s shown below
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true,
CallingConvention = CallingConvention.Winapi)]
public static extern int FormatMessage(int dwFlags, int lpSource, int dwMessageId,
int dwLanguageId, out StringBuilder lpBuffer,
int nSize, IntPtr va_list);
The extension method used is the following
public static class ExceptionExtension {
/// <summary>
/// Gets the win32 error description.
/// </summary>
/// <param name="ex">The ex.</param>
/// <returns></returns>
public static Win32Error GetWin32ErrorDescription(this Exception ex) {
Win32Error retval = Win32Error.Empty;
StringBuilder pMsgBuf = new StringBuilder();
int lastError = FormatErrorHelper.GetLastError();
FormatErrorHelper.FormatMessage(
FormatErrorHelper.FORMAT_MESSAGE_ALLOCATE_BUFFER |
FormatErrorHelper.FORMAT_MESSAGE_FROM_SYSTEM,
FormatErrorHelper.NULL, lastError,
FormatErrorHelper.MakeLangID(FormatErrorHelper.LANG_NEUTRAL,
FormatErrorHelper.SUBLANG_DEFAULT), out pMsgBuf, 0, IntPtr.Zero);
retval.ErrorCode = lastError;
retval.Description = pMsgBuf != null ? pMsgBuf.ToString() : string.Empty;
return retval;
}
}
So if we catch any exception, besides obtaining the exception object itself we get the error and message code from the operating system
Win32Error osError = Win32Error.Empty;
// Some funky exception here...
osError = ex.GetWin32ErrorDescription();
Console.WriteLine(string.Format("Code: {0} - Description: {1}",
new object[] {osError.ErrorCode, osError.Description}));
If we implement everything we’ve previously mentioned, see the difference between the exception message and the message provided by the operating system
![image_thumb[2]](http://msmvps.com/cfs-file.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/angelhernandez.metablogapi/5810.image_5F00_thumb2_5F00_6E1B5EFB.png "image_thumb[2]")
Hope this helps,
Regards,
Angel
El manejo estructurado de excepciones, es una de las características que como desarrolladores utilizamos más a menudo, ya no es necesario estar implementando etiquetas On Error u otro mecanismo poco elegante para manejar condiciones de error, sin embargo el .NET Framework es una capa entre el sistema operativo y nuestra aplicación, aunque la clase Exception describe una condición de error, carece del código de error y descripción asociado al sistema operativo, en muchas ocasiones el interpretar algunas excepciones puede llegar en cierto punto ser algo frustrante porque no es muy descriptivo, por lo que no sería mala idea recuperar la información de error emitida por Windows. Con el paso de los años, el API de Windows ha crecido y así mismo la cantidad de mensajes de error subyacentes, en el SDK de la plataforma se consigue información sobre estos mensajes de error y lo mismo sucede con el WDK, por lo que se me ocurrió la idea de extender la clase Exception a través de un método de extensión. Los métodos de extensión, nos permiten “agregar “métodos a tipos de datos existentes sin la necesidad de crear un tipo derivado, recompilar ó modificar el tipo original. Estos métodos son un tipo especial de método estático que son llamados como si fueran métodos de instancia en el tipo extendido. Su uso más común es con LINQ para así conseguir funcionalidad adicional de los tipos IEnumerable e IEnumerable<T>.
Para recuperar la descripción de un código de error utilizamos la función FormatMessage, como mostramos a continuación
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true,
CallingConvention = CallingConvention.Winapi)]
public static extern int FormatMessage(int dwFlags, int lpSource, int dwMessageId,
int dwLanguageId, out StringBuilder lpBuffer,
int nSize, IntPtr va_list);
El método de extensión utilizado con la clase Exception es el siguiente
public static class ExceptionExtension {
/// <summary>
/// Gets the win32 error description.
/// </summary>
/// <param name="ex">The ex.</param>
/// <returns></returns>
public static Win32Error GetWin32ErrorDescription(this Exception ex) {
Win32Error retval = Win32Error.Empty;
StringBuilder pMsgBuf = new StringBuilder();
int lastError = FormatErrorHelper.GetLastError();
FormatErrorHelper.FormatMessage(
FormatErrorHelper.FORMAT_MESSAGE_ALLOCATE_BUFFER |
FormatErrorHelper.FORMAT_MESSAGE_FROM_SYSTEM,
FormatErrorHelper.NULL, lastError,
FormatErrorHelper.MakeLangID(FormatErrorHelper.LANG_NEUTRAL,
FormatErrorHelper.SUBLANG_DEFAULT), out pMsgBuf, 0, IntPtr.Zero);
retval.ErrorCode = lastError;
retval.Description = pMsgBuf != null ? pMsgBuf.ToString() : string.Empty;
return retval;
}
}
Por lo que al atrapar alguna excepción, además de obtener el objeto Exception como tal también obtengo el código y mensaje de error del sistema operativo
Win32Error osError = Win32Error.Empty;
// Some funky exception here...
osError = ex.GetWin32ErrorDescription();
Console.WriteLine(string.Format("Code: {0} - Description: {1}",
new object[] {osError.ErrorCode, osError.Description}));
Si ponemos en práctica todo lo mencionado anteriormente, vean lo diferente que es el mensaje de proporcionado por el .NET Framework al del sistema operativo
Espero sea de utilidad,
Saludos,
Angel
I usually read a lot about technology stuff from Microsoft and other vendors as well. One of my favourite sites to gather information about ongoing projects and things to come is Microsoft Research so today after having lunch I started to browse for some projects and I found Pex which in my humble opinion seems to be really interesting, why? Because it’s a new tool that helps in understanding the behavior of .NET code, debugging issues, and in creating a test suite that covers all corner cases – fully automatically. Through a context menu in the code editor, the user can invoke Pex to analyze an entire class or a single method. For any method, Pex computes and displays interesting input-output pairs. Pex systematically hunts for bugs – exceptions or assertion failures. As Pex discovers boundary conditions in code, Pex generates new tests that target these conditions. The result is a small test suite with high code coverage. Pex enables Parameterized Unit Testing, an extension of traditional unit testing that reduces test maintenance costs. Pex has been used in Microsoft to test core .NET components. Pex is developed at Microsoft Research and is integrated into Microsoft Visual Studio, so if you’re like me that loves to deliver high quality code then Pex is a must in your toolbox.
Regards,
Angel
Usualmente leo bastante sobre tecnologías Microsoft y otros fabricantes también. Uno de mis sitios favoritos para conseguir información acerca de proyectos en ejecución y cosas por venir es Microsoft Research así que hoy después de almorzar comencé a navegar por algunos proyectos y encontré Pex, el cual en mi humilde opinión parece ser realmente interesante, ¿por qué? Pues porque es una nueva herramienta que ayuda a entender el comportamiento de código .NET, problemas de depuración y en la creación de pruebas para la mayoría de los casos – todo esto de manera automática. A través de un menú contextual en el editor de código, el usuario puede invocar Pex para analizar una clase entera ó un sólo método. Para cualquier método, Pex calcula y muestra las entradas y las salidas. Pex sistemáticamente busca bugs – excepciones ó fallas de aserciones. Mientras Pex descubre las condiciones de límites en el código, a su vez genera nuevas pruebas para dichas condiciones. El resultado es una pequeña suite con alta cobertura de código. Pex permite realizar prueba unitarias parametrizadas, que son una extensión de las pruebas unitarias tradicionales que reducen los costos en el mantenimiento de las pruebas. Pex ha sido utilizado por Microsoft para probar componentes importantes de .NET. Pex es desarrollado en Microsoft Research y está integrado con Microsoft Visual Studio, así que si eres como yo que le encanta entregar código de alta calidad entonces Pex es indispensable en tu caja de herramientas.
Saludos
Yesterday afternoon I was coming home on the train, when suddenly I had this idea of writing something about policy injection, function pointers and my preference of using .NET instead of Java. Firstly, allow me to get started with policy injection, it’s a definition commonly used in developer talks but, what does it mean? Or what is it about? In a few words we can define it as “one technique becoming increasingly popular by the adoption of Aspect Oriented Programming (AOP), which provides an array of mechanisms to change the behavior of business objects and other classes by applying policies thus making it easier to implement crosscutting concerns such as logging, validation, exception handling, caching and more”.
The terminology of AOP uses the word “concern” to mean a task or feature of an application. Core concerns are the features usually unique to a class or object, for example, a class to connect to a database or serialize an object to disk. Tasks common to more than one class or object are crosscutting concerns. Poor management of these can result in duplicated and hard-to-manage code, and unreliable applications.
Policy injection was introduced by the Microsoft patterns & practices group into the release (version 3.0) of their Enterprise Library which integrates with the other application blocks in the library. The latest version can be downloaded here
However, I would like to share with you the idea or principle behind “Policy injection”, if you’re like me that prefer designing and writing all the components for an application by yourself, this can be a useful post to you then.
In my humble opinion, we have at least two possible ways to “inject” either by using generics or through callbacks (delegates), let’s proceed to describe them:
1-.Using Generics: Generics was introduced in .NET 2.0 and it gives us the ability to write “generic” code plus enforcing type-safety, I mean, no more casting to object to achieve multiple reuse. Let’s suppose we have the following class
It implements the ISample interface which contains a single method PerformAction that throws an exception if the time’s current second is even (we do this to simulate that something goes wrong during the execution of this method), please note that we don’t have any exception handling in that method. Now, let’s suppose that I have heaps of classes implementing the same interface without any exception handling mechanism too, what could I possibly do in that case? If we take into consideration the definitions for concern and crosscutting concern we can then say: I have different concerns (even when the implemented interface is the same) but at the same time I have crosscutting concerns, I mean, all of my classes implement this interface without a proper exception handling mechanism.
Having said that, let’s have a look at the following code fragment
It’s a generic class and its usage is restricted to ISample objects plus requires the creation of a new instance, in its Ctor, through Reflection we collect information of the class used with the generic class, I mean, the object we’ll be applying our “policy” to. The generic class contains only a method called Execute which invokes the PerformAction method of our class implementing ISample hence exception handling is added which it didn’t exist in our original implementation.
The implementation on the client or application would be like this
Please note that I didn’t have to modify the original code but I’m using another mechanism instead, in this case “Policy injection” through a generic class that acts as a proxy which allows me to achieve what I want plus isolating concerns from each other but considering crosscutting concerns.
2-.Using Callbacks: Callbacks, function pointers or delegates refer to the same mechanism for passing executable code as an argument to another code. In old C/C++ school we can do it like this
However in .NET we do it like this
So the way we can achieve “policy injection” through callbacks differs a little from the one previously explained, which is cleaner, easier to maintain and suggested from my point of view, because we use a proxy that communicates with the class we’re applying the policy to; if we’re using callback it would be something like this
The greater difference between the two approaches, it’s that policy code is on the client side and not in the proxy class, so code is repeated and future maintainability is at risk. We can achieve what we want but it’s not the best approach to follow, however this method it’s pretty useful in situations such as, impersonating a given user to execute a piece of code.
Changing topics and almost wrapping up, one of the reasons I prefer .NET instead of Java it’s because of Callbacks support which have been with us for a long time ago and they’re a pretty useful as we can see, for instance, the qsort function (quicksort implementation in CRT) which expects to receive as last parameter a Callback to a comparison function. In Java we don’t have this functionality out-of-the-box but we need to “simulate it” by implementing interfaces (Callback pattern) and I start wondering, what the heck? I can do this in C/C++ using native code and in any other .NET language without implementing any “pattern” so I can focus on the requirement, for reasons like this and many other reasons I prefer .NET instead of Java because it just makes me more productive.
Regards,
Angel
Ayer en la tarde venía en el tren hacia mi casa, cuando de repente se me ocurrió la idea de escribir algo acerca de inyección de políticas, punteros a función y mi preferencia de .NET antes que Java. Primero, permítanme comenzar con inyección de políticas, es un término que se escucha comúnmente en conversaciones de desarrolladores, pero ¿qué significa ó de que trata? En pocas palabras lo podríamos definir como “Una técnica que se está popularizando con la adopción de la programación orientada a aspectos (AOP), la cual brinda distintos mecanismos para cambiar el comportamiento de objetos de negocios y otras clases a través de la aplicación de políticas, facilitando así la implementación común de conceptos como validación, registro de eventos, manejo de excepciones y caché y muchas más”.
En AOP, se utiliza el término concepto para referirse a una tarea ó característica de una aplicación. Los conceptos claves son características únicas de una clase u objeto, por ejemplo, una clase para conectarse a una BD ó serializar un objeto a disco. Las tareas comunes para una clase u objeto se denomina “funcionalidad transversal” (en inglés, cross-cutting), que en muchas oportunidades un mal manejo de estas trae como consecuencia código duplicado y difícil de mantener sin mencionar aplicaciones poco confiables.
La inyección de políticas fue introducida en .NET por Microsoft con la versión de 3 de su librería de aplicaciones empresarial, la cual trae consigo un componente de inyección de políticas que se integra con los otros componentes de dicha librería. La última versión se puede descargar acá
Sin embargo, me gustaría compartir con ustedes la idea ó el principio de detrás de la “inyección de políticas”, si ustedes son como yo que prefieren diseñar y desarrollar todos los componentes de una aplicación entonces este post puede ser de utilidad.
En mi humilde opinión tenemos dos posibles maneras de “inyectar” bien sea usando Generics y un poco de Reflection ó a través del uso de Callbacks (delegados), a continuación describiremos las dos:
1-. Haciendo uso de Generics: Generics fue introducido en .NET 2.0 y nos ofrece la posibilidad de escribir código más “genérico” esforzando la tipificación de los datos, es decir, no más casting a Object para conseguir reutilización múltiple. Supongamos que tenemos la siguiente clase
La cuál implementa la interfaz ISample que posee un sólo método PerformAction que arroja una excepción si el segundo actual es par (esto para simular que algo falla con la ejecución de dicho método), nótese que no tenemos manejo de excepciones en ese método. Ahora supongamos que tengo un montón de clases que implementan la misma interfaz pero con la misma carencia de manejo de excepciones, ¿en ese caso qué puedo hacer? Sí tomamos en consideración las definiciones de concepto y funcionalidad transversal, podemos entonces decir: Tengo distintos conceptos (porque aunque la interfaz implementada es común su implementación es distinta) pero a su vez tengo funcionalidad transversal, es decir, todas mis clases que implementan la interfaz ISample necesitan un manejo de excepciones.
Una vez dicho eso, obsérvese el siguiente fragmento de código
Es una clase genérica a la cual restringimos su uso para objetos que implementen la interfaz ISample además que su utilización requiere una instancia de objeto, en el constructor a través de Reflection obtenemos información de la clase usada con la clase genérica, es decir, el objeto al cuál le aplicaremos la “política”. La clase genérica tiene sólo un método llamado Execute que invoca ó llama a su vez al método PerformAction de la clase que implementa ISample y agrega manejo de excepciones la cual no existía en la implementación original.
La manera de utilizarlo desde el cliente ó nuestra aplicación sería así
Nótese que no tuve que modificar el código original sino que hago uso de otro mecanismo, en este caso “inyección de políticas” que a través de una clase genérica que actúa como proxy el cuál me permite conseguir lo que quiero, así aislando mis conceptos pero tomando en consideración la funcionalidad transversal.
2-. Haciendo uso de Callbacks: Los Callbacks, punteros a función ó delegados se refieren al mismo mecanismo de pasar código ejecutable como argumento a otro código. En la vieja escuela C/C++ podríamos conseguirlo así
Sin embargo en .NET lo hacemos así
Entonces la manera que podríamos lograr ó conseguir la “inyección de políticas” difiere un poco de la descrita previamente que es más limpia, adecuada, fácil de mantener y la recomendada desde mi punto de vista, porque hacemos uso de un Proxy que se comunica con la clase a la cual se le aplica la política; caso que difiere de hacerlo con un Callback como se muestra a continuación
La mayor diferencia como se puede notar, es que el código que pertenece a la política está del lado del cliente y no en el proxy como tal, permitiendo así repetir código y poner en riesgo el mantenimiento futuro. Podemos conseguir lo que queremos pero no es la mejor manera de hacerlo, sin embargo este segundo enfoque es realmente útil para casos en los cuales, por ejemplo quiera impersonar a un usuario para correr un fragmento de código
Cambiando de tema y ya casi para finalizar, una de las razones por la cual prefiero .NET en vez de Java es por el soporte y uso de Callbacks los cuales están con nosotros desde siempre y son muy útiles como el caso de la función qsort (Implementación de quicksort en el CRT) que acepta como último argumento una función que se encarga de comparar los elementos que se desean ordenar sin mencionar el poder de pasar funciones a funciones. En Java, esto simplemente no “existe” si no hay que “simular conseguirlo” a través de la implementación de interfaces (Patrón de Callback) por lo que me pregunto, ¿qué rayos es eso? Lo puedo hacer en C/C++ en código nativo y en cualquier lenguaje .NET sin implementar ningún tipo de “patrón” para así enfocarme en el requerimiento, por esta y muchas otras razones que .NET me hace más productivo lo prefiero antes que Java.
Saludos,
Angel
A couple of days ago I was writing a piece of code for a Sharepoint solution which has Forms based authentication enabled. I had to invoke some SharePoint WebServices but the only thing standing in the way... FBA (Forms Based Authentication) so after receiving a couple of 403 errors I realized that I had to change my approach. It's really easy and straightforward do this using SSPI (Windows Integrated Security, a.k.a. NTLM and Kerberos) because you just need to do something like this
but it's a different story when your authentication mechanism is not SSPI and for that purpose we have authentication.asmx located in the _vti_bin folder but before we proceed any further I'd like to add a comment in regards SharePoint's WebServices
It's required to set the service's URL before calling it, for instance
http://server/_vti_bin/authentication.asmx
however I want to authenticate or access a resource in a given site then I must specify this Url
http://server/MySite/_vti_bin/authentication.asmx
The following code snippet illustrates how to do it
Regards,
Angel
Hace un par de días estaba escribiendo un fragmento de código para una solución basada en SharePoint con autenticación basada en formas habilitada. Tenía que invocar unos servicios Web de SharePoint pero lo único que tenía en el camino... Autenticación basada en formas por lo que después de recibir un par de errores 403 me dí cuenta que tenía que cambiar el enfoque y manera de hacer las cosas. Es realmente fácil y sencillo hácerlo con SSPI (Seguridad Integrada de Windows, conocido como NTLM y Kerberos) porque lo único que se necesita hacer es algo como esto
Pero es una historia distinta cuando el mecanismo de autenticación no es SSPI y para esos casos tenemos authentication.asmx que se encuentra en la carpeta _vti_bin folder sin embargo antes de proseguir me gustaría agregar un comentario en relación a los servicios Web de SharePoint
Es requerido establecer el URL del servicio antes de realizar alguna llamada, por ejemplo
http://server/_vti_bin/authentication.asmx
pero si quiero autenticarme o acceder un recurso en un sitio dado entonces debo especificar este Url
http://server/MySite/_vti_bin/authentication.asmx
El siguiente fragmento de código ilustra como hácerlo
Saludos,
Angel
I just finished setting up my PC to have a dual boot (Windows Vista x64 & Mac OS X Leopard), I'm an Microsoft MVP and I love Microsoft tecnologies (I've been using Microsoft software since MS-DOS 3.3 and GW-BASIC) but you all know me, I'm always trying to find a new challenge 
so I decided to get started writing applications for iPhone OS and see how can integrate these applications with Microsoft technologies, I've written C# and C++ for a while but now my time to learn Objective-C has come 
It's pretty funny this fact because like two weeks ago I found out that some gold partner here in Sydney didn't like my "strong C++ background" and the guy who interviewed me consider C/C++ "impure" ha ha ha that was the silliest thing I've ever heard in my life, right Richard? Anyways... I love to integrate technologies and play with them, my current project at Customware is about integrating SAP, Microsoft CRM, SharePoint, webMethods, .NET 3.5, ASP.NET and AJAX so integration is not new to me, as a matter of fact, I have a couple of Virtual Machines (Solaris Express Edition & Ubuntu) running on VirtualBox for some integration stuff I'm currently working on as well... Anyways, I'm really excited about this and I'll keep you posted on this "integration wave" so I'm cross-platform, baby...
Cheers,
Angel
Acabo de terminar de configurar mi PC para que tuviera una arranque dual (Windows Vista x64 & Mac OS X Leopard), soy un MVP de Microsoft y amo las tecnologías Microsoft (He estado utilizando software Microsoft desde MS-DOS 3.3 y GW-BASIC) pero todos ustedes me conocen , estoy siempre tratando de encontrar un nuevo reto por lo que decidí comenzar a escribir aplicaciones para el iPhone OS y así ver como puedo integrar estas aplicaciones con tecnologías Microsoft, he escrito código en C# y C++ por un rato y ahora debo aprender Objective-C Es curioso esto porque hace como dos semanas atrás descubrí que un gold partner acá en Sydney no le gustó mi "fuerte influencia de C++" y la persona que me entrevistó considera a C/C++ "impuros" ja ja ja eso fue lo más estúpido que he escuchado en mi vida, verdad Richard? En fin... Disfruto mucho integrar tecnologías y jugar con ellas, mi proyecto actual en Customware tiene que ver con integrar SAP, Microsoft CRM, SharePoint, webMethods, .NET 3.5, ASP.NET y AJAX por lo que integrar no es nuevo para mi, de hecho tengo un par de máquinas virtuales (Solaris Express Edition & Ubuntu) corriendo en VirtualBox para algunas cosas de integración en los que actualmente también estoy trabajando... De cualquier forma, estoy realmente emocionado acerca de esto y los mantendré informado en esta "ola de integración" por lo que puedo decir soy plataforma cruzada, nena...
Saludos,
Angel
LINQ is a very powerful feature in .NET, however its syntax can be a bit confusing sometimes for some developers plus having the ability to perform queries in our code it’s not a novelty either, I did some FoxPro in the past and this capability was present already, so using and implementing LINQ it’s not that difficult to me =) Anyways… Some days ago I had to write and implement some caching mechanism on this SharePoint based solution I’m currently working on which integrates SAP, CRM, WebMethods, AJAX and so on. The issue I had was related to grouping data based on more than one column (which it’s not LINQ’s out-of-the-box functionality), let’s remember that grouping it’s provided by the Queryable class and my working data was based on a DataTable which it’s a totally different class… so I came with this easy and quick idea to implement, since I’m using LINQ to ADO.NET and DataSets as well as DataTable don’t contain the AsQueryable extension method I had to create a “pseudo” extension method to handle DataRow collections then use a Func delegate which is going to be passed to the IEnumerable<T>.GroupBy extension method, you may be wondering by now, but what does the method targeted by the delegate do? Well… It’s a very simple a short answer, I just create a unique key (used to group my data) based on concatenating the value for the columns I want to group by and voila! it’s works… It’s not hard or time consuming to implement and it gives me the results that I’m expecting. The images shown below illustrate the code that’s required to accomplish this.
Kind regards,
Angel
LINQ es una característica muy poderosa en .NET, sin embargo su sintaxis puede ser un poco confusa algunas veces para los desarrollares, además la capacidad de realizar consultas en nuestro código tampoco es una novedad, yo desarrollé con FoxPro en el pasado y ésta característica estuvo siempre presente, así que utilizar ó implementar LINQ no es tan difícil para mí =) En fin… Hace unos días atrás tuve que escribir e implementar un mecanismo de caché para ésta solución basada en SharePoint en la que trabajo actualmente la cual integra SAP, CRM, WebMethods, AJAX y pare usted de contar. El problema que tenía era en relación al agrupamiento de datos basado en más de una columna (Lo cuál no es una funcionalidad por defecto en LINQ), recordemos que el agrupamiento está dado por la clase Queryable y mis datos estaban almacenados en un DataTable los cuales son una clase totalmente distinta, por lo que se me ocurrió ésta idea que resultó ser rápida y fácil de implementar; ya que estoy utilizando LINQ con ADO.NET y DataSets al igual que DataTable no contienen el método de extensión AsQueryable tuve entonces que crear un “pseudo” método de extensión para manipular una colección de DataRow que me permitiera después utilizar un delegado Func que posteriormente es pasado al método de extensión IEnumerable<T>.GroupBy, ustedes se estarán preguntándose ahora, pero qué hace el método apuntado por el delegado? Bueno… Es una respuesta corta y sencilla, sólo creo una clave única (utilizada para agrupar mis datos) a partir de concatenar el valor de las columnas por la cual quiero agrupar y voila! Funciona… No es díficil ó toma tiempo para hácerlo y me da los resultados que espero. Las imágenes mostradas a continuación contienen el código que es necesario para conseguir esto.
Saludos cordiales,
Angel
Image 1 – GetTestData method
Image 2 – GroupData method
Image 3 – EnumerableDataRowExtension class
Image 4 – PerformDataGrouping method
Image 5 – It’s so easy to do in FoxPro =)
Have you ever wanted to browse code metrics based on a code base or manage complexity and dependency plus get to know how your code is structured and even more? If that’s your case then you should try Visual NDepend. This tool based on 4 different inputs (Image 1):
-
.NET Assemblies
-
.NET PDB Files
-
C# Source Files
-
Coverage Files
Performs an analysis and tells us more about our code in just minutes. The “easiest” and most common way to measure any code base is through counting the number of lines of code which at the end is a time consuming and boring task, Visual NDepend does a much more than that because it supports CQL (Code Query Language) so we can query our code based on a given criteria and focus on design and architecture without incurring in dependencies faults in the event of refactoring.
The user interface is pretty straightforward (Image 2), just create a new project, add assemblies to be analized and go. The hardest part but after a while becomes easy is the ability to interpret analysis output results (Image 3) but like everything else in life… it’s all about practice.
At the end of the analysis we get a report which is a condensed view about our code structure and organization (Image 4), we can also see where we are in terms of abstractness and instability (Image 5)
So if you’re a developer or architect who expects nothing more than clean and reusable code, this tool is the right for you.
Kind regards,
Angel
¿Alguna vez has querido navegar a través de las métricas basadas en tu código base ó manejar la complejidad y dependencia, además de llegar a saber como está estructurado tu código y aún más? Sí ese es tu caso entonces deberías probar Visual NDepend. Ésta herramienta basada en 4 entradas diferentes (Imagen 1):
-
Ensamblajes de .NET
-
Archivos PDB
-
Código fuente de C#
-
Archivos de Cobertura
Realiza un análisis y nos dice más de nuestro código en cuestión de minutos. La manera “más fácil” y común de medir cualquier código base es a través del conteo del número de líneas de código lo cual resulta ser una tarea aburrida que consume bastante tiempo, Visual NDepend hace mucho más que eso porque soportaCQL (Lenguaje de Consulta de Código) así que podemos consultar nuestro código basado en un criterio dado y enfocarnos en el diseño y arquitectura sin incurrir en faltas asociadas a dependencias en el caso que tengamos que refactorizar.
La interfaz es realmente sencilla (Imagen 2), sólo crear un nuevo proyecto, agregar ensamblajes para analizar y ejecutar. La parte más díficil pero después de un tiempo se hace sencilla es la habilidad de interpretar el resultado del análisis (Imagen 3) pero como todo en la vida… es sólo práctica.
Al final del análisis obtenemos un reporte el cual es una vista condensada acerca de la estructura y organización de nuestro código (Imagen 4), también podemos ver en donde nos encontramos en términos de abstracción e inestabilidad (Imagen 5)
Así que si eres un desarrollador ó un arquitecto que no espera sino código limpio y reutilizable, esta es la herramienta adecuada para ti.
Saludos cordiales,
Angel
Image 1 – NDepend Analysis inputs
Image 2 – NDepend welcome screen
Image 3 – NDepend dependency matrix and metrics
Image 4 – NDepend analysis report
Image 5 – Abstractness vs. Instability
Last year 2008 was challenging, amazing and exciting all at the same time. I’ve had a lot of interesting experiences and situations alike that goes from moving countries (Venezuela to Australia), joining CustomWare, my first speaking engagement in Tech-Ed and so on. I’ve learned a lot generally speaking so I hope this year 2009 can be better than the previous one. As developers, we can’t escape the fact that our code is not bug free (we wish it was but life ain’t perfect) so this post is about some useful debugging tips and options we have available
Option #1 – Visual Studio .NET Debugger
This is our first line of defense, but it’s missing 99% of the times on a production environment. It allows to set breakpoints, add watches, evaluate expressions, view memory and its disassembly and something even cooler… We can step into .NET Framework code (Image 1)
Option #2 – CorDebug
It’s a pretty cool tool which allows us to debug .NET code using the command line. It takes some time to get used to the commands but once we do it, it’s pretty straightforward. It’s highly recommended to have the symbols files (PDB) required to step into the code. If we don’t have it then we’re going to see the code in Assembler. Let’s take as an example the Test.cs source file (Image 2), it’s a very simple application written with “Visual” Notepad.
Then we’re going to compile it using the CSC from the Command Prompt. We can either generate symbols/debug information or not with the following switches:
· Generate Debug Information
csc test.cs /platform:x64 /debug
· Don’t generate any Debug Information
csc test.cs /platform:x64
Once we’ve built our assembly/application we can launch CorDebug and start debugging it. We can either let CorDebug launch the application for us or we can attach it to the selected process by ourselves. Image 3 depicts the CorDebug “interface”.
The yellow rounded rectangles indicate:
1. Listing of managed applications running
2. Attach the debugger to process 1372
We can execute ? anytime to get information about available commands. The following image shows CorDbg launching the application for us and we step into the code (The lines are retrieved from the PDB file and code executed outside our program is displayed in Assembler). The colour reference (Image 4) for the rounded rectangles is:
· Light Green: CorDbg launching c:\test.exe
· Light Blue: Assemblies loaded
· Yellow: Stepping into the code
· Red: Displaying and modifying variables
· Grey: Stack trace at that moment
· Cyan: Modules loaded plus Application Domain ID
Option #3 – WinDbg (Windows Debugging Tools)
It’s a multipurpose debugger that can be used to debug user mode applications, drivers and the operating system itself in kernel mode. It’s very useful to debug kernel-mode memory dumps, created after an application crashes or when experiencing a “BSoD”. This tool allows to step into the code if PDB (symbol file) is present (Image 5).
WinDbg allows loading of extension DLLs that can augment the debugger's supported commands and allow for help in debugging specific scenarios: for example, displaying an MSXML document given an IXMLDOMDocument, or debugging the Common Language Runtime (CLR). These extensions are a large part of what makes WinDbg such a powerful debugger. WinDbg is used by the Microsoft Windows product team to build Windows, and everything needed to debug Windows is included in these extension DLLs.
Option #4 – CLR Profiler
Believe it or not but this tool helped me a lot 4 years ago when one of the projects I was engaged on at that time started to act “weird”… By using CLR Profiler and Windows Monitoring and Performance tools I was able to find a memory leak issue with BSTR objects. CLRProfiler is a tool that you can use to analyze the behavior of your managed applications which is focused on analyzing what is going on in the garbage collector heap (Image 6) and you can get an overview of your application’s memory usage (Image 7).
Option #5 – .NET Reflector
Originally developed by Lutz Roeder and now by Red Gate Software, this tool is really handy and a “must-have” in every .NET developer toolbox because it allows you to Disassemble and analyze .NET assemblies (Image 8) so you can check and step into .NET code without having the source files.
Option #6 – Fiddler
Have you ever wanted to sniff HTTP requests/responses? If that’s the case then you might find Fiddler useful. It’s a light-weight sniffing tool which allows developers see what’s happening between client/server HTTP transmission (Image
9) Option #7 – Microsoft NetMon (Network Monitor)
A couple of months ago I had an issue related to Kerberos, it seemed that the Kerberos ticket was getting lost somewhere… My best choice for this kind of situations, NetMon (Image 10). It’s a complete sniffing and network monitoring tool by Microsoft.
Option #8 – Windows’ performance and monitoring Tools
Task Manager, Performance Monitor can make our lives easier if we know how to use them and most important… Add the right performance counter to determine and detect any possible problem.
Hope this helps,
Kind regards,
Angel
El año pasado 2008 fue retador, interesante y emocionante todo al mismo tiempo. Tuve un montón de experiencias y situaciones por igual que van desde cambiar de países (de Venezuela para Australia), unirme a CustomWare, mis primeras charlas en Tech-Ed y pare usted de contar. He aprendido generalmente hablando así que espero que este año 2009 pueda ser mejor que el anterior. Como desarrolladores, no podemos escapar el hecho de que nuestro código no está libre de errores (así lo quisierámos pero la vida no es perfecta) por lo que este post trata sobre algunos tips y opciones que tenemos disponibles
Opción #1 – Depurador de Visual Studio .NET
Esta es nuestra primera línea de defensa, pero el 99% de las veces no está instalado en un ambiente de producción. Nos permite establecer puntos de interrupción, inspección de variables, evaluar expresiones, ver la memoria y su desensamblado y algo aún más chévere… Podemos ver código del .NET Framework (Imagen 1)
Opción #2 – CorDebug
Es una herramienta bien interesante que nos permite depurar código de .NET desde la línea de comandos. Toma algo de tiempo acostumbrarse a los comandos pero una vez que lo hacemos, es realmente sencillo. Es altamente recomendado tener los símbolos (PDB) requeridos para poder ver el código. Sí no lo tenemos entonces vamos a ver el código en Ensamblador. Ahora tomemos como ejemplo el archivo Test.cs (Imagen 2), es una aplicación bastante sencilla escrita con “Visual” Notepad.
Luego vamos a compilarla utilizando CSC desde la línea de comandos. Podemos generar ó no símbolos (información de depuración) con los siguientes switches:
· Generar información de depuración
csc test.cs /platform:x64 /debug
· No generar información de depuración
csc test.cs /platform:x64
Una vez que hayamos generado nuestro ensamblaje/aplicación podemos ejecutar CorDebug y comenzar a depurar. Podemos ejecutar la aplicación por nuestra cuenta ó podemos adjuntarlo al proceso seleccionado.La imagen 3 muestra la “interfaz” de CorDebug “.
Los rectángulos amarillos indican:
1. Lista de aplicaciones administradas en ejecución
2. Adjuntar el depurador al proceso 1372
Podemos ejecutar ? en cualquier momento para obtener información de comandos disponibles. La siguiente imagen muestra a CorDbg lanzando la aplicación por nosotros y podemos ver el código (Las líneas de código se recuperan del archivo PDB y el código ejecutado fuera de nuestro programa es mostrado en Ensamblador). La referencia del color (Imagen 4) de los rectángulos es:
· Verde claro: CorDbg lanzando c:\test.exe
· Azul claro: Ensamblajes cargados
· Amarillo: Ejecución línea por línea del código
· Rojo: Mostrando y modificando variables
· Gris: Pila de llamadas al momento
· Aguamarina: Módulos cargados además del ID AppDomain
Opción #3 – WinDbg (Windows Debugging Tools)
Es un depurador multi-propósito que puede ser utilizado para depurar aplicaciones en modo usuario, controladores y al mismo sistema operativo en modo Kernel. Es muy útil para depurar vaciados de memoria en modo Kernel, que son creados después de una aplicación haberse cerrado inesperadamente ó tras experimentar una “Pantalla Azul”. Esta herramienta permite ejecutar el código línea por línea sí el archivo de símbolos (PDB) está presente (Imagen 5)
WinDbg permite cargar DLLs de extensión que pueden aumentar los comandos soportados por el depurador permitiendo así depurar en escenarios específicos: Por ejemplo, mostrar un documento MSXML a partir de un objeto IXMLDOMDocument ó inclusive depurar el Common Language Runtime (CLR). Estas extensiones hacen de WinDbg un poderoso depurador. WinDbg es utilizado por el equipo de desarrollo de Microsoft Windows y todo lo necesario para depurar Windows está incluído en estas DLLs de extensión.
Opción #4 – CLR Profiler
Creánlo ó no pero esta herramienta me ayudó mucho hace 4 años atrás cuando uno de los proyectos en los que estaba involucrado para ese entonces comenzó a actuar “raro”… Al utilizar el CLR Profiler y las herramientas de rendimiento y monitoreo de Windows pude encontrar una fuga de memoria relacionada con objetos de tipo BSTR. El CLR Profiler nos permite analizar lo que sucede en el montón del colector de basura (Imagen 6) así mismo podemos obtener un resumen del uso de la memoria por parte de la aplicación (Imagen 7).
Opción #5 – .NET Reflector
Originalmente desarrollado por Lutz Roeder y ahora por Red Gate Software, esta herramienta es realmente útil y “necesaria-tener” en la caja de herramientas de cada desarrollador .NET ya que permite analizar y decompilar ensamblajes de .NET (Imagen 8) por lo que se puede chequear y revisar el código sin necesidad de tener los archivos fuentes.
Opción #6 – Fiddler
¿Alguna vez has deseado escuchar solicitudes/respuestas basadas en HTTP? Sí es ese el caso, entonces encontrarás a Fiddler útil (Imagen
9). Es una herramienta liviana para escuchar conversaciones basadas en HTTP entre el cliente y el servidor. Opción #7 – Microsoft NetMon (Network Monitor)
Hace un par de meses atrás se me presentó un problema relacionado con Kerberos, parecía que el ticket de Kerberos se estaba perdiendo en alguna parte… Mi mejor opción para ese tipo de situaciones, NetMon (Imagen 10). Es una herramienta completa para escuchar el tráfico y conversaciones en la Red.
Opción #8 – Herramientas de rendimiento y monitoreo de Windows
El administrador de tareas y monitor de rendimiento pueden hacer nuestras vidas más fáciles si sabemos como usarlos y lo más importante… Agregar el contador de rendimiento adecuado para detectar y determinar cualquier posible problema.
Espero sea de utilidad,
Saludos cordiales,
Angel
Image 1 – Yes… We want to step into the Framework code :D
Image 2 – Simple application written in Visual “Notepad