SharePoint script fails when run as a command after deploying Visual Studio

Question

I wrote 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 the library will not be empty after retraction and deployment.

Relevant parts of the script:

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

It works great at startup, as follows from the command line, even immediately after redeploying Visual Studio:

 powershell \ source \ ProjectFiles \ TestData \ Install.ps1

However, this does not work when I use the same command as on the command line after deployment in the properties of a SharePoint project 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

Interestingly, I can reproduce the error on the command line if I run:

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

However, the command after deployment fails even if I explicitly run \windows\System32\WindowsPowerShell\v1.0\powershell and \windows\Syswow64\WindowsPowerShell\v1.0\powershell .

Update: solution found

It seems I have a similar problem with the one discussed here:

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

I cannot access the 64-bit SharePoint API using 32-bit clients. Because Visual Studio is 32-bit, the post-deployment action will be executed in a 32-bit process and will fail. However, there is 64-bit MSBuild. If we let him run the PowerShell script, everything will be fine.

Wrap the script in an MSBuild file, for example:

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

Then set the command line after deployment to:

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

Answer 1

Using

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

It is important that you use the virtual path% WINDIR% \ SysNative, and not the actual path to C: \ Windows \ System32. The reason for this is because 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 bookmark.

(c) Inside Microsoft SharePoint 2010, Microsoft Press, March 2011

Answer 2

I had the same situation, I needed PowerPoint to deploy the script to create dummy data for the lists in my local instance. I tried several other ways, even using MSBuild with the .msbuild file, as suggested above, but I could not use all the variables and had to hardcode the file using the path and URL, but I did not want this.

I finally figured out a way to explicitly call the 64-bit powershell.exe file

I know that a 64-bit file must be on the hard drive. I know that in the WinSXS folder there are all files. So a quick search for powershell.exe in the folder C: \ Windows \ winsxs I have two files, so I grabbed the path for one in the amd64 folder.

This is what I have as a command in the option after deployment

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

I hope this helps someone in the future.

Answer 3

Visual Studio is a 32-bit application, so on 64-bit Windows it runs in a simulated 32-bit environment.

It is strange that the 32-bit environment is called “WoW64” (when 32-bit Windows did this for 16-bit applications, it was called “WoW16”. The “WoW” part means “Windows on Windows”.

Oddly enough, "System32" did not become "System64" with 64-bit Windows. “32” is a transition from a 16-bit → 32-bit transition to distinguish it from the “System”. No matter what legacy / compatibility is for you.

In WoW64, everything looks like 32-bit Windows.

For example, c:\windows\system32 simply points to c:\windows\syswow64 . 32-bit applications cannot (easily) achieve anything 64-bit.

You can use PowerShell Remoting to get a 64-bit PowerShell session from a 32-bit environment.

 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 4

I have success by doing this as a command after deployment:

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