Ver video 
Scripting siempre ha sido una bisagra entre administradores y desarrolladores, Powershell (implementación de .Net CLI y el futuro estándar de scripting de Microsoft Sharepoint ) permite reutilizar librerías .Net y COM.
Powershell mantiene un mecanismo de referencia similar al que estamos acostumbrados a trabajar en .Net – en términos conceptuales – pero no tiene una IDE que permita administrar esas referencias.
Para bien o para mal todo se hace en el archivo de texto, por ejemplo para establecer parámetros iniciales hay que colocar algo parecido a esto al principio:
param( [string]$strSourceFolder = $(throw "Indique la carpeta a respaldar"), [string]$strDestinationFolder = $(throw "Indique la carpeta de destino"))
(No lo pongan en otro lugar que al principio).
Si quieren saber que ensamblados están referenciados (Powershell es una aplicación .Net):
[appdomain]::currentdomain.getassemblies()
Tal como puede inferirse ejecutamos así el método estático CurrentDomain en System.AppDomain para obtener el conjunto de ensamblados en el domino activo.
Tenemos toda la disponibilidad de objetos que nos permita la seguridad del SO, así que pueden ir al explorador de objetos de Visual Studio y ejecutar los métodos que quieran del tipo – en este caso – appDomain.
Y así siempre…
¿Quieren cargar librerías de Sharepoint?
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
¿Quieren referenciar sus propias librerías sin agregarlas al GAC?
[System.Reflection.Assembly]::Loadfile("C:\ElPathDeLaDLLCOMPLETO\MiLibreria.dll")
En esto nos vamos a basar para escribir una librería que funciona en Sharepoint y puede ser invocada desde Powershell.
Hay un problema histórico de fácil resolución que pocas veces se resuelve: alguien se olvida del Dispose.
Y se va a volver a olvidar: él u otro. Condición del ser humano, ¿vió señora?.
So, so…en vez de pasar un objeto que necesita ser liberado invertimos el proceso y pasamos de ser proveedores de objetos a consumidores de funciones.
No proveemos un objeto SPSite ó SPWeb sino que recibimos una función como parámetro utilizando delegados.
public delegate void ConsumeSiteWeb(SPSite sitio, SPWeb web);
Cualquier subrutina sin valor de retorno con esos parámetros puede ser recibida por una función con una firma como ésta:
public static void ProvideSiteWeb(string url, List<ConsumeSiteWeb> funcs)
¿Por qué una lista como parámetro?
Porque puedo recibir un conjunto de llamados si es necesario y optimizar la instanciación de los objetos.
¿Le voy a pedir a un administrador que maneje el Dispose y le voy a explicar el modelo línea a línea de proceso en Powershell para que haga todo en la misma línea?
¡Con el siguiente Script puedo importar los datos de una tabla de SQL Server a una lista de Sharepoint!
$splib= [System.Reflection.Assembly]::Loadfile("C:\Users\Administrator\Desktop\Carpetas\Proyectos\SP_Library\bin\Debug\SP_Library.dll")
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server=MOSS;Database=AdventureWorks;Integrated Security=True"
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = "SELECT TOP 1000 [ContactID]
,[FirstName]
,[MiddleName]
,[LastName]
,[Suffix]
,[EmailAddress]
,[Phone]
,[ModifiedDate]
FROM [AdventureWorks].[Person].[Contact]"
$SqlConnection.Open()
$SqlCmd.Connection = $SqlConnection
$SqlCmd.CommandTimeout = 0
$dr = $SqlCmd.ExecuteReader()
[SP_Library.Importer]::ToList("Contacts", $dr)
$SqlConnection.Close()
Powershell usa "$" en las variables como XSL, "{}" como C# y no es Case Sensitive como Visual Basic, cuando quieran comentar un párrafo no hagan pruebas: es "#". La vida es dura…
Les dejo la solución completa para que prueben aquí