SharePoint guión falla cuando se ejecuta como un comando posterior a la implementación de Visual Studio

Question

He escrito un guión que introduce algunos datos de prueba en una biblioteca de documentos. Tengo la intención de utilizarlo como un paso posterior a la implementación en Visual Studio 2010, para que la biblioteca no esté vacía después de una retractación & implementar.

Las partes pertinentes de la secuencia de comandos son:

Install.ps1:

$scriptDirectory = Split-Path -Path $script:MyInvocation.MyCommand.Path -Parent 
. "$scriptDirectory\Include.ps1" 

$webUrl = "http://localhost/the_site_name" 
$web = Get-SPWeb($webUrl) 
... 

Include.ps1:

function global:Get-SPSite($url) 
{ 
    return new-Object Microsoft.SharePoint.SPSite($url) 
} 
function global:Get-SPWeb($url,$site) 
{ 
    if($site -ne $null -and $url -ne $null){"Url OR Site can be given"; return} 

    #if SPSite is not given, we have to get it... 
    if($site -eq $null){ 
     $site = Get-SPSite($url); 

    ... 
} 

Funciona bien cuando se ejecuta como se desprende de la línea de comandos, incluso inmediatamente después de volver a implementar Visual Studio:

 
powershell \source\ProjectFiles\TestData\Install.ps1 

Sin embargo, no funciona cuando se utiliza el mismo comando exactamente como una línea de comandos posterior a la implementación en las propiedades del proyecto de SharePoint en Visual Studio:

 
Run Post-Deployment Command: 
New-Object : Exception calling ".ctor" with "1" argument(s): "The Web applicati 
on at http://localhost/the_site_name could not be found. Verify that you have t 
yped the URL correctly. If the URL should be serving existing content, the syst 
em administrator may need to add a new request URL mapping to the intended appl 
ication." 
At C:\source\ProjectFiles\TestData\Include.ps1:15 char:18 
+ return new-Object <<<< Microsoft.SharePoint.SPSite($url) 
    + CategoryInfo   : InvalidOperation: (:) [New-Object], MethodInvoca 
    tionException 
    + FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.Power 
    Shell.Commands.NewObjectCommand 

Curiosamente, puedo reproducir el error en la línea de comandos si funciono:

 
c:\windows\Syswow64\WindowsPowerShell\v1.0\powershell \source\ProjectFiles\TestData\Install.ps1 

Sin embargo, el comando pos-implementación falla incluso si me quedo explícitamente \windows\System32\WindowsPowerShell\v1.0\powershell y \windows\Syswow64\WindowsPowerShell\v1.0\powershell.

Actualización: Solución encontró

Me parece estar teniendo un problema similar al discutido aquí:

http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/faa25866-330b-4e60-8eee-bd72dc9fa5be

No puedo acceder a una API de SharePoint de 64 bits con 32 bits clientela. Dado que Visual Studio es de 32 bits, la acción posterior a la implementación se ejecuta en un proceso de 32 bits y se producirá un error. Sin embargo, hay un MSBuild de 64 bits. Si permitimos que ejecute el script de PowerShell, todo está bien.

Wrap la secuencia de comandos en un MSBuild de archivo como este:

<?xml version="1.0" encoding="utf-8"?> 
<Project DefaultTargets="Install" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <Target Name="Install"> 
    <Exec Command="powershell .\Install" /> 
    </Target> 
</Project> 

A continuación, establezca la línea de comandos posterior a la implementación de:

 
%WinDir%\Microsoft.NET\Framework64\v4.0.30319\MSBuild $(SolutionDir)\ProjectFiles\TestData\Install.msbuild 

Answer 1

Visual Studio es una aplicación de 32 bits , por lo que en Windows de 64 bits que se ejecuta en un entorno simulado de 32 bits.

Curiosamente, el entorno de 32 bits se llama "WoW64" (cuando Windows de 32 bits hizo esto para aplicaciones de 16 bits, se le llamó "WoW16". La "sorpresa" parte significa "de Windows en Windows".

se es similarmente extraño que "System32" no se convirtió en "System64" con Windows de 64 bits el "32" es de la de 16 bits -. transición> 32 bits, para diferenciarse de "Sistema" lo que sea, eso es. legado/compatibilidad para usted.

En WoW64, todo parece un Windows de 32 bits.

Por ejemplo, c:\windows\system32 solo puntos a c:\windows\syswow64. Las aplicaciones de 32 bits no pueden (fácilmente) alcanzar nada de 64 bits.

Es posible utilizar PowerShell Remoting para obtener una sesión de 64 bits de PowerShell desde un entorno de 32 bits.

 
PS>gci env:PROCESSOR_ARCH* 

Name       Value 
----       ----- 
PROCESSOR_ARCHITECTURE   x86 
PROCESSOR_ARCHITEW6432   AMD64 


PS>Invoke-Command -ConfigurationName Microsoft.PowerShell -ComputerName LOCALHOST { gci env:PROCESSOR_ARCH* } 

Name       Value          PSComputerName 
----       -----          -------------- 
PROCESSOR_ARCHITECTURE   AMD64          localhost 

Answer 2

Tuve la misma situación, necesitaba el script Post Deployment Powershell para crear datos ficticios para listas en mi instancia local. Intenté varias otras maneras incluso usando MSBuild con el archivo .msbuild como se sugirió anteriormente, pero no pude todas las variables y tuve que codificar el archivo con ruta y url, esto no es lo que quería.

finalmente me di cuenta de una manera de llamar explícitamente la powershell.exe 64 bits

sé el archivo de 64 bits tiene que estar allí el dirve duro. Sé que la carpeta WinSXS tiene todos los archivos. Así que búsqueda rápida de powershell.exe en la carpeta C: \ Windows \ winsxs obtuve dos archivos, así que agarré la ruta para uno en la carpeta amd64.

Esto es lo que tengo como mando opción de implementación posterior

C:\Windows\winsxs\amd64_microsoft-windows-powershell-exe_31bf3856ad364e35_6.1.7600.16385_none_c50af05b1be3aa2b\powershell.exe -command "&{$(ProjectDir)PowerShell\dataload.ps1 -xmlPath "$(ProjectDir)PowerShell\dataload.xml" -webUrl "$(SharePointSiteUrl)"}" 

en espero que esto ayude a alguien en el futuro.

Answer 3

Uso

% windir% \ SysNative \ WindowsPowerShell \ v1.0 \ powershell.exe

Es importante que utilice la ruta de acceso virtual% windir% \ SysNative y no trayectoria real de C : \ Windows \ System32. La razón de esto es que Visual Studio 2010 es una aplicación de 32 bits que hay que llamar a la versión de 64 bits de powershell.exe para cargar con éxito el Microsoft.SharePoint.PowerShell complemento.

(c) "dentro de Microsoft SharePoint 2010", de Microsoft Press, mar 2011

Answer 4

tengo éxito haciendo esto como una orden de despliegue mensaje:

%comspec% /c powershell -File "c:\foo\bar.ps1"