Question:
I have written a script that inserts some test data into a document library. I intend to use it as a post-deployment step in Visual Studio 2010, so that the library is not empty after a retract & deploy.
The relevant portions of the script are:
Install.ps1:
1 2 3 4 5 6 7 |
$scriptDirectory = Split-Path -Path $script:MyInvocation.MyCommand.Path -Parent . "$scriptDirectory\Include.ps1" $webUrl = "http://localhost/the_site_name" $web = Get-SPWeb($webUrl) ... |
Include.ps1:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
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); ... } |
It works fine when run as follows from the command line, even immediately after a Visual Studio re-deploy:
1 |
powershell \source\ProjectFiles\TestData\Install.ps1 |
However, it does not work when I use the exact same command as a post-deployment command line in the SharePoint project’s properties in Visual Studio:
1 2 3 4 5 6 7 8 9 10 11 12 |
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 |
Interestingly, I can reproduce the error on the command line if I run:
1 |
c:\windows\Syswow64\WindowsPowerShell\v1.0\powershell \source\ProjectFiles\TestData\Install.ps1 |
However, the post-deployment command fails even if I explicitly run \windows\System32\WindowsPowerShell\v1.0\powershell
and \windows\Syswow64\WindowsPowerShell\v1.0\powershell
.
Update: Solution found
I seem to be having a similar problem to the one discussed here:
I cannot access a 64-bit SharePoint API using 32-bit clients. Because Visual Studio is 32-bit, the post-deployment action will run in a 32-bit process and will fail. There is, however, a 64-bit MSBuild. If we let it run the PowerShell script, all is fine.
Wrap the script in an MSBuild file such as this:
1 2 3 4 5 6 7 |
Then, set the post-deployment command line to:
1 |
%WinDir%\Microsoft.NET\Framework64\v4.0.30319\MSBuild $(SolutionDir)\ProjectFiles\TestData\Install.msbuild |
Answer:
Use
%WINDIR%\SysNative\WindowsPowerShell\v1.0\powershell.exe
It’s important that you use the virtual path of %WINDIR%\SysNative and not the actual
path of C:\Windows\System32. The reason for this is that Visual Studio 2010 is a 32-bit
application that needs to call the 64-bit version of powershell.exe to successfully load the
Microsoft.SharePoint.Powershell snap-in.
(c)”Inside Microsoft SharePoint 2010″, Microsoft Press, Mar 2011