RunspaceConfiguration psConfig = RunspaceConfiguration.Create();
Runspace psRunspace = RunspaceFactory.CreateRunspace(psConfig);
psRunspace.Open();
using (Pipeline psPipeline = psRunspace.CreatePipeline())
{
// Define the command to be executed in this pipeline
Command command = new Command("Add-spsolution");
// Add a parameter to this command
command.Parameters.Add("literalpath", #"c:\project3.wsp");
// Add this command to the pipeline
psPipeline.Commands.Add(command);
// Invoke the cmdlet
try
{
Collection<PSObject> results = psPipeline.Invoke();
Label1.Text = "hi"+results.ToString();
// Process the results
}
catch (Exception exception)
{
Label1.Text = exception.ToString();// Process the exception here
}
}
It is throwing the exception:
System.Management.Automation.CommandNotFoundException: The term 'add-spsolution' is not recognized as the name of a cmdlet, function, script file, or operable program.
Any suggestions why?
Add this command first:
Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0
You must use the import-module command to load the correct module for sharepoint. Use get-module to find available modules.
To do this programmatically, see my post on the subject:
http://www.nivot.org/2010/05/03/PowerShell20DeveloperEssentials1InitializingARunspaceWithAModule.aspx
-Oisin
I have this issue recently. In my case I was neither able to see the added solution nor able to add solution. So first I remove solution using below PowerShell Command:
(Get-SPSolution -Identity "YourSolution.wsp").Delete()
Then I was able to add my new code solution.
Also make sure you are runing "Add-SPSolution" command from Web Applications, which is running on IIS, and NOT with standard Visual Studio server (when you press F5).
Related
Just trying to create a script to install IIS and Management Tools and getting the error below, any idea what could be the cause of it?
Configuration iis_dsc_file
{
# Import the module that contains the resource we are using.
Import-DSCResource -ModuleName PsDesiredStateConfiguration
Import-module servermanager
# The Node statement specifices which targets this configuration will be applied to.
Node localhost
{
# Code to ensure IIS feature is enabled
WindowsFeature WebServer
{
Ensure= "Present"
Name= "Web-Server"
}
WindowsFeatures IISManagementTools {
Name= "Web-Mgmt-Tools"
Ensure= "Present"
IncldueAllSubFeature= $True
LogPath= "C:\ServerLogs\IIS-Installation-Log.txt"
}
}
}
The error message I get is below:
The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: The term 'WindowsFeatures' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Any idea what is the issue?
It fails because there is an extra S at the end of the second WindowsFeature
By the way, IncldueAllSubFeature is misspelled too, it should be IncludeAllSubFeature
I'm building a desktop app for Windows using electron-packager and electron-squirrel-startup, I would like to execute some Windows cmd commands during the installation of my application. To do so I was planning to use node-cmd node module, but I doesn't really work inside the handleSquirrelEvents function. An example command like this:
function handleSquirrelEvent(application) {
const squirrelEvent = process.argv[1];
switch (squirrelEvent) {
case '--squirrel-install':
case '--squirrel-updated':
var cmd=require('node-cmd');
cmd.run('touch example.created.file');
}
};
Seems to work. A file example.created.file in my_app/node_module/node-cmd/example directory is created.
But any other code does not work. Even if I only change the name of the file to be "touched" nothing happens.
Ok, example.created.file already exists in this directory and I suspect that you can only use update.exe supported commands in case '--squirrel-updated' sections. So this will not work.
I have a VM template that deploys a DSC extension. It's been working fine but my configuration is growing so I've refactored it to use a composite resource and republished it to blob storage with Publish-AzureRmVMDscConfiguration.
I verified that the .ps1.zip file in blob storage contains my custom module and that the module is listed under dscmetadata.json. However, when I deploy, the DSC extension fails. The logs under C:\WindowsAzure\Logs\Plugins\Microsoft.Powershell.DSC\2.17.0.0 reveal the reason:
C:\Packages\Plugins\Microsoft.Powershell.DSC\2.17.0.0\bin..\DSCWork\AppServerDev.ps1.0\AppserverDev.ps1
PSDesiredStateConfiguration\node : The module 'xCustomResource' could
not be loaded. For more information, run 'Import-Module
xCustomResource'.
At C:\Packages\Plugins\Microsoft.Powershell.DSC\2.17.0.0\DSCWork\AppServerDev.ps1.0\AppserverDev.ps1:9 char:3
node "localhost"
~~~~
CategoryInfo : ObjectNotFound: (xCustomResource\xCustomResource:String)
[PSDesiredStateConfiguration\node], ParentContainsErrorRecordException
FullyQualifiedErrorId : CouldNotAutoLoadModule,PSDesiredStateConfiguration\node
Here are the relevant bits of my configuration file:
configuration AppServerDev
{
param($environment)
Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
Import-DscResource -ModuleName 'SaaSModule'
node "localhost"
{
LocalConfigurationManager
{
RebootNodeIfNeeded = $true
ConfigurationMode = "ApplyAndAutoCorrect"
ConfigurationModeFrequencyMins = 1440
}
xDCTPlatformVM VM {
OctopusParametersFile = $environment
ChocolateyPackages = #(
'googlechrome',
'notepadplusplus',
'7zip',
'microsoftwse',
'octopusdeploy.tentacle',
'sqlserver-cmdlineutils'
)
}
}
}
Running Get-Module -ListAvailable reveals that DankModule is found and I can, from powershell, run Import-Module DankModule and it works as expected. I assume the confusion is coming from it trying to import xCustomResource rather than DankModule but my .ps1 file under C:\Packages\Plugins\Microsoft.Powershell.DSC\2.17.0.0\DSCWork says
Import-Module "DankModule"
and not
Import-Module "xCustomType"
Why is it trying to import xCustomType rather than DankModule? How do I make it find DankModule which is available and contains xCustomType?
UPDATE: Get-Module -ListAvailable shows DankModule is installed but Get-DSCResource -Module DankModule doesn't return anything.
I'm not sure but I think this is a rookie mistake on my part because I have no experience building powershell modules. I was using this page as well as this one to construct my module and I'd gotten a valid module file by using New-ModuleManifest, I had the correct file structure mentioned in both of them e.g.
C:\Program Files\WindowsPowerShell\Modules\
DankModule
DankModule.psd1
DankModule.psm1
DSCResources
xCustomResource
xCustomResource.psd1
RootModule = ‘xCustomResource.schema.psm1'
xCustomResource.schema.psm1
Configuration, no Node block
but I didn't realize I had some tweaking left. I needed to correct the RootModule property in DankModule.psd1 to look like this:
RootModule = 'C:\Program Files\WindowsPowerShell\Modules\DankModule\DankModule.psm1'
And also needed to add to my blank DankModule.psm1 a line referencing my xCustomResource.schema.psm1 equivalent:
. .\DSCResources\xCustomResource\xCustomResource.schema.psm1
That is the only line in my module-level .psm1 file and everything is now working. I also, at one point, removed all the \0s from both my .psd1 files but now I'm not sure if that was strictly necessary.
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:
$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 fine when run as follows from the command line, even immediately after a Visual Studio re-deploy:
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:
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 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:
http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/faa25866-330b-4e60-8eee-bd72dc9fa5be
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:
<?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 post-deployment command line to:
%WinDir%\Microsoft.NET\Framework64\v4.0.30319\MSBuild $(SolutionDir)\ProjectFiles\TestData\Install.msbuild
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
I had same situation, I needed the Post Deployment powershell script to create dummy data for lists on my local instance. I tried several other ways even using the MSBuild with the .msbuild file as suggested above, but i could not all the variables and had to hard code the file with path and url, this is not what i wanted.
I finally figured out a way to explicitly calling the 64-Bit powershell.exe
I know the 64-bit file has to be there on hard dirve. I know that WinSXS folder has all the files. So quick search for powershell.exe in C:\Windows\winsxs folder i got two files so i grabbed the path for one in amd64 folder.
This is what i have as command in post deployment option
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 will help someone in future.
Visual Studio is a 32-bit application, so in 64-bit Windows it runs in a simulated 32-bit environment.
Strangely, the 32-bit environment is called "WoW64" (when 32-bit Windows did this for 16-bit apps, it was called "WoW16". The "WoW" part means "Windows on Windows".
It's similarly strange that "System32" didn't become "System64" with 64-bit Windows. The "32" is from the 16-bit -> 32-bit transition, to differentiate from "System". Whatever, that's legacy/compatibility for you.
In WoW64, everything looks like a 32-bit Windows.
For example, c:\windows\system32 just points to c:\windows\syswow64. 32-bit applications can't (easily) reach anything 64-bit.
It is possible to 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
I have success doing this as a post deployment command:
%comspec% /c powershell -File "c:\foo\bar.ps1"
I'm writing a groovy script that I want to be controlled via a properties file stored in the same folder. However, I want to be able to call this script from anywhere. When I run the script it always looks for the properties file based on where it is run from, not where the script is.
How can I access the path of the script file from within the script?
You are correct that new File(".").getCanonicalPath() does not work. That returns the working directory.
To get the script directory
scriptDir = new File(getClass().protectionDomain.codeSource.location.path).parent
To get the script file path
scriptFile = getClass().protectionDomain.codeSource.location.path
As of Groovy 2.3.0 the #SourceURI annotation can be used to populate a variable with the URI of the script's location. This URI can then be used to get the path to the script:
import groovy.transform.SourceURI
import java.nio.file.Path
import java.nio.file.Paths
#SourceURI
URI sourceUri
Path scriptLocation = Paths.get(sourceUri)
Note that this will only work if the URI is a file: URI (or another URI scheme type with an installed FileSystemProvider), otherwise a FileSystemNotFoundException will be thrown by the Paths.get(URI) call. In particular, certain Groovy runtimes such as groovyshell and nextflow return a data: URI, which will not typically match an installed FileSystemProvider.
This makes sense if you are running the Groovy code as a script, otherwise the whole idea gets a little confusing, IMO. The workaround is here: https://issues.apache.org/jira/browse/GROOVY-1642
Basically this involves changing startGroovy.sh to pass in the location of the Groovy script as an environment variable.
As long as this information is not provided directly by Groovy, it's possible to modify the groovy.(sh|bat) starter script to make this property available as system property:
For unix boxes just change $GROOVY_HOME/bin/groovy (the sh script) to do
export JAVA_OPTS="$JAVA_OPTS -Dscript.name=$0"
before calling startGroovy
For Windows:
In startGroovy.bat add the following 2 lines right after the line with
the :init label (just before the parameter slurping starts):
#rem get name of script to launch with full path
set GROOVY_SCRIPT_NAME=%~f1
A bit further down in the batch file after the line that says "set
JAVA_OPTS=%JAVA_OPTS% -Dgroovy.starter.conf="%STARTER_CONF%" add the
line
set JAVA_OPTS=%JAVA_OPTS% -Dscript.name="%GROOVY_SCRIPT_NAME%"
For gradle user
I have same issue when I'm starting to work with gradle. I want to compile my thrift by remote thrift compiler (custom by my company).
Below is how I solved my issue:
task compileThrift {
doLast {
def projectLocation = projectDir.getAbsolutePath(); // HERE is what you've been looking for.
ssh.run {
session(remotes.compilerServer) {
// Delete existing thrift file.
cleanGeneratedFiles()
new File("$projectLocation/thrift/").eachFile() { f ->
def fileName=f.getName()
if(f.absolutePath.endsWith(".thrift")){
put from: f, into: "$compilerLocation/$fileName"
}
}
execute "mkdir -p $compilerLocation/gen-java"
def compileResult = execute "bash $compilerLocation/genjar $serviceName", logging: 'stdout', pty: true
assert compileResult.contains('SUCCESSFUL')
get from: "$compilerLocation/$serviceName" + '.jar', into: "$projectLocation/libs/"
}
}
}
}
One more solution. It works perfect even you run the script using GrovyConsole
File getScriptFile(){
new File(this.class.classLoader.getResourceLoader().loadGroovySource(this.class.name).toURI())
}
println getScriptFile()
workaround: for us it was running in an ANT environment and storing some location parent (knowing the subpath) in the Java environment properties (System.setProperty( "dirAncestor", "/foo" )) we could access the dir ancestor via Groovy's properties.get('dirAncestor').
maybe this will help for some scenarios mentioned here.