I'm following the instructions from here:
http://scottmuc.com/blog/development/pester-bdd-for-the-system-administrator/
I'm finding that having installed and imported the module I still can't run Create-Fixture.
Has anyone come across this?
Turns out Create-Fixture isn't a cmdlet any more. I had a look here:
https://github.com/mwrock/Chocolatey-Packages/blob/master/pester/Pester.psm1
and realised the name of the cmdlet has been changed. It's now called New-Fixture.
If you run New-Fixture it even references Create-Fixture:
PS D:\edsource\Powershell> New-Fixture
invalid usage, please specify (path, name)
eg: .\Create-Fixture -Path Foo -Name Bar
creates .\Foo\Bar.ps1 and .\Foo.Bar.Tests.ps1
Related
After I imported the module 'virtualmachinemanager' in Powershell (PS 5.1) the cmdlet Stop-Job becomes an alias of Stop-SCJob. I checked that the cmdlet works before importing. Futhermore I tried to make an custom alias for Stop-Job before importing. But sadly that alias also refers to Stop-SCJob after the import.
I also tried to find something on Google, but no luck yet.
Anyone has seen this behaviour before? And more important how do I fix this?
Thanks in advance.
You could simply remove the alias: Remove-Item Alias:\Stop-Job (with -ErrorAction Ignore if you want to handle the case where there's no alias). If you want to refer to the original cmdlet without removing the alias, you can use Microsoft.PowerShell.Core\Stop-Job.
Thanks to Jeroen Mostert
I am working on a project that utilizes a PowerShell script that creates a new login on a remote SQL Server (SSMS) and then checks to see if a particular folder exists on the server. If the folder does not already exist, the script will create that folder.
The issue I am having is that I cannot verify whether or not the folder exists since the path I am testing is a UNC path of the form "\\server\Files\Log". I have tried many different solutions that I have found through a couple hours of searching online, and all solutions return FALSE even though I am testing a server and folder I know already exist.
I am using PowerGUI to write my script and my system is using PowerShell v5. What I have tried so far:
Test-Path $path (where $path has been set to \\server)
Test-Path "filesystem::\\Srv"
[System.IO.Directory]::Exists($path)
I even tried [System.IO.Directory]::Exists('G:\') using all of the
letters I have network servers mapped to to see if I needed to map to the drives to make it work (all returned FALSE)
What am I missing here? Any thoughts on this topic would be greatly appreciated as I have been grinding on this for a while with no progress being made.
EDIT: For anyone who might stumble upon this later, please read the comments, which I found to be super helpful. My main issue was that I was running PowerShell as an administrator which does not have the same permissions as my normal user account. Also note that Test-Path \\server alone does not work, a folder must also be referenced.
You already have the correct answer:
Test-Path $path
or
Test-Path \\server.domain.tld\ShareName
If Test-Path is returning false, I can think of three things that could be wrong:
The share does not exist on that server, or at least with the name you expect
Your user does not have permission to read that share
You are specifying the short name of the server, and you need the FQDN to resolve it. This is common in multidomain environments.
After re-reading your question, it looks like you might be running Test-Path \\server. You cannot check for the existence of a server this way, you have to specify both the server and the share name at a minimum. If you want to know that a server exists and is online, use Test-Connection (assuming you are able to ping this server in the first place). Here is an example of using Test-Connection:
$serverName = 'server.domain.tld'
$sharePath = 'ShareName' # you can append more paths here
if( Test-Connection $serverName 2> $null ){
Test-Path "\\${serverName}\${sharePath}"
}
I used to have an issue where the file existed, but test-path is returning false. I put test-path in a loop that checks a maximum of 10 x, with a one sec pause in between. The script works fine now. If on the first attempt it does not find the file on the second or third it does. Not sure why it returns false on the first attempt.
I’m running into this error while trying to convert my Windows Forms Application using Project Centennial. I was able to run threw the shown VLC tutorial on the MSDN site, so I do know the converter is working. It says I need to “set the 'Application Executable' property in the AppxManifest.xml before calling makeappx manually” but I am not sure how to do that. I have tried using -AppExecutable but it’s not setting, every time it builds it defaults to MyApp.exe. It says I can edit it, but when I do not know how to call MakeAppx.exe with the same XML file.
Here is the command I am using:
.\DesktopAppConverter.ps1 -ExpandedBaseImage C:\ProgramData\Microsoft\Windows\Images\BaseImage-14393 –Installer C:\Users\Mark\Desktop\Newest_Installer\Keyed-Setup.exe -InstallerArguments "/S" -Destination C:\Users\Mark\Desktop\Keyed_App_Filers -PackageName "Keyed" -Publisher "CN=JonesComm" -Version 1.0.2.2 -AppExecutable "KeyedApp.exe" -MakeAppx -Verbose
Here is a picture of the full error.
Error Pic
Thanks in advance for any help you can offer!
Eureka!!! Okay so for about a week solid I have not been able to get this right. I have an MSI and a .exe of my program and I just successfully wrapped the .aapx with the MSI. The command that lead to the break though was “msiexec /?” this shows a list of the commands specifically for that application. “/PASSIVE” is the command needed to run without UI. I was able to set the 'Application Executable' property with “-AppExecutable "Executable(.exe) File Path"-AppInstallPath "Your Applications Installation Path” This is just the name of your applications executable, and where that executable would be located on a new computer after a fresh install.
Here is an editable version of the powershell command I used:
.\DesktopAppConverter.ps1 -ExpandedBaseImage C:\ProgramData\Microsoft\Windows\Images\BaseImage-14393 –Installer C:\Users \Desktop\MyApp\MyApp_Setup.msi -InstallerArguments "/PASSIVE" -Destination C:\Users\Desktop\MyApp-Appx -PackageName "MyApp" -Publisher "CN=Company" -Version 1.0.2.2 -AppExecutable "ApplicationFolder\SubFolder\MyApp.exe"-AppInstallPath "C:\Program Files (x86)\ApplicationFolder\SubFolder" -MakeAppx -Verbose
I hope this helps any newbies out there like me. Project Centennial doesn’t have much for tutorials out there right now. Thanks everyone!!
I used sitecore powershell last year to migration heaps of items.
I installed the latest one and I don't see "Initialization script" field under Console/All Users item.
I had used this field to intialize all my custom scripts like below so that I can access from PSE.
Execute-Script -Item (Get-Item -ID "{0B0E50B9-CD3C-4FE7-BB6D-D2A9AAEB7568}" -Path master:\)
Any help will be good.
This was removed in SPE 3.1 due to the unpredictable nature.
https://github.com/SitecorePowerShell/Console/issues/365
If you could post a new issue on what your custom script does, perhaps we can provide you with an alternate solution.
After reading several other blog posts and articles (references found below) there appear to be several ways to run PowerShell on .NET 4.0 but few are sufficient for our purposes. Due to how we deploy our software we cannot update the registry or change add an application. This leaves us with two options, create our own shell by using ConsoleShell or override PSHost. We would like to be able to use the first option, ConsoleShell, due to it's simplicity but would like to know what issues we may encounter and whether doing so is recommended.
Reference
Based on other questions I have seen that you can use the following methods to run PowerShell as .NET 4.0. None of these methods appear to be officially sanction by Microsoft but the first shown below is included as a work around in this Microsoft connect issue.
The options to run PowerShell in .NET 4.0 appear to include:
Update the app.config to include .NET 4.0 as supported
Add a registry setting to switch the version
Use ConsoleShell to host your own PowerShell Console
Implement your own PowerShell host, PSHost , as done by PoshConsole or Nuget
As far as it is not officially approved (to my knowledge), then nobody can approve it but you. If your scenario works and passes reasonable tests, approve and use it.
I use PowerShell on .NET 4.0 but with the option 4, and used to use the option 1, too (I do not like the option 2, personally). Thus, I approved it, production or not, I use it a lot and it works. I still use PowerShell on .NET 2.0 for two reasons: 1) PowerShell.exe starts faster (especially x64); 2) to be sure that part of my PowerShell development is compatible with .NET 2.
Another thought. If something does not work properly in PowerShell on .NET 2.0 (there are some issues, indeed, see Connect) then the fact "it is approved for production" itself does not help much. One has to overcome existing issues, .NET 2 or .NET 4 does not matter.
P.S. I should have mentioned that I tried the option 3 as well. I did not find use cases suitable for using it in my scenarios. But I did not find any issues in using ConsoleShell either.
P.P.S Yet another option. Make a copy of PowerShell.exe, rename it into MyConsoleShell.exe, use it together with MyConsoleShell.exe.config configured for .NET 4. As far as you are going to use a separate application anyway, then why not to consider this?
I'm a bit of a powershell N00b, but I threw this together as a way of forcing an arbitrary script to use .NET 4.0 in my script:
# Place this at the top of your script, and it will run as a .NET 4 ps script.
# #############################################################################
if ($PSVersionTable.CLRVersion.Major -lt 4) { try {
$cfgPath = $Env:TEMP | Join-Path -ChildPath ([Guid]::NewGuid())
mkdir $cfgPath | Out-Null
"<configuration><startup useLegacyV2RuntimeActivationPolicy='true'><supportedRuntime version='v4.0'/></startup></configuration>" | Set-Content -Path $cfgPath\powershell.exe.activation_config -Encoding UTF8
$darkMagic = 'COMPLUS_ApplicationMigrationRuntimeActivationConfigPath'
$old = [Environment]::GetEnvironmentVariable($darkMagic)
[Environment]::SetEnvironmentVariable($darkMagic, $cfgPath)
& powershell.exe $MyInvocation.MyCommand.Definition $args
} finally {
[Environment]::SetEnvironmentVariable($darkMagic, $old)
$cfgPath | Remove-Item -Recurse
return
}}
# ##############################################################################
# My script starts here:
echo "Your arguments are: $args "
echo "The CLR Major Version is : $($PSVersionTable.CLRVersion.Major)"
It places a check in the beginning of the script, and if it's not .NET 4.0 it creates a configuration file, sets an environment variable and re-runs the powershell script so that it runs under .NET 4.0.
it does incur a bit of a startup time penalty of about a second or so on my pc, but at least it works :)