Lo script di SharePoint non riesce quando viene eseguito come comando post-distribuzione di Visual Studio

Question

Ho scritto uno script che inserisce alcuni dati di test in una libreria di documenti. Intendo utilizzarlo come passaggio successivo alla distribuzione in Visual Studio 2010, in modo che la libreria non sia vuota dopo una ritrazione & distribuita.

Le porzioni rilevanti dello script sono:

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); 

    ... 
} 

Funziona bene quando viene eseguito come segue da la riga di comando, anche immediatamente dopo una distribuzione di Visual Studio:

 
powershell \source\ProjectFiles\TestData\Install.ps1 

Tuttavia, non funziona quando uso lo stesso comando esattamente come una riga di comando post-distribuzione nelle proprietà del progetto di SharePoint in 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 

È interessante notare che, posso riprodurre l'errore sulla riga di comando se corro:

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

Tuttavia, il comando post-distribuzione non riesce, anche se corro esplicitamente \windows\System32\WindowsPowerShell\v1.0\powershell e \windows\Syswow64\WindowsPowerShell\v1.0\powershell.

Aggiornamento: Soluzione trovato

mi sembra di avere un problema simile a quello discusso qui:

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

Non è possibile accedere un'API SharePoint a 64 bit utilizzando 32 bit clienti. Poiché Visual Studio è a 32 bit, l'azione successiva alla distribuzione verrà eseguita in un processo a 32 bit e avrà esito negativo. C'è, tuttavia, un MSBuild a 64 bit. Se gli permettiamo di eseguire lo script di PowerShell, tutto andrà bene.

Avvolgere lo script in un MSBuild file come ad esempio questo:

<?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> 

Quindi, impostare la riga di comando post-distribuzione a:

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

Answer 1

Visual Studio è un 32-bit applicazione , quindi in Windows a 64 bit viene eseguito in un ambiente simulato a 32 bit.

Stranamente, l'ambiente a 32 bit si chiama "WoW64" (quando Windows a 32 bit lo faceva per le app a 16 bit, veniva chiamato "WoW16" .La parte "WoW" significa "Windows su Windows."

È strano che "System32" non sia diventato "System64" con Windows a 64 bit. Il "32" è dalla transizione 16-bit-32-bit, per differenziare da "Sistema". legacy/compatibilità per voi.

In WoW64, tutto sembra un Windows a 32 bit.

Ad esempio, c:\windows\system32 punta solo a c:\windows\syswow64. Le applicazioni a 32 bit non possono (facilmente) raggiungere qualcosa a 64 bit.

È possibile utilizzare Remot PowerShell per ottenere una sessione PowerShell a 64 bit da un ambiente a 32 bit.

 
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

avevo stessa situazione, avevo bisogno lo script PowerShell post installazione per creare dati fittizi per gli elenchi sulla mia istanza locale. Ho provato diversi altri modi anche usando MSBuild con il file .msbuild come suggerito sopra, ma non potevo tutte le variabili e ho dovuto codificare il file con path e url, non è quello che volevo.

ho finalmente trovato un modo per chiamare in modo esplicito il powershell.exe 64 bit

So che il file a 64 bit deve essere lì sul dirve duro. So che la cartella WinSXS ha tutti i file. Quindi, la ricerca rapida di powershell.exe nella cartella C: \ Windows \ winsxs mi ha dato due file, quindi ho afferrato il percorso per uno nella cartella amd64.

Questo è quello che ho come comando opzione di distribuzione postale

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)"}" 

in Spero che questo vi aiuterà qualcuno in futuro.

Answer 3

Utilizzo

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

E 'importante utilizzare il percorso virtuale del% WINDIR% \ SysNative e non l'attuale percorso di C : \ Windows \ System32. La ragione di ciò è che Visual Studio 2010 è un'applicazione a 32 bit che deve chiamare la versione a 64 bit di powershell.exe per caricare correttamente lo snap-in Microsoft.SharePoint.Powershell .

(c) "Inside Microsoft SharePoint 2010", Microsoft Press, Mar 2011

Answer 4

ho successo facendo questo come un comando distribuzione postale:

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