I am running a powershell script in the Post-Build event in Visual Studio (VS). Here is a simplified version of the command command

powershell -ExecutionPolicy remotesigned -File "%SampleDir%\update.ps1" "$(ProjectDir)" "$(TargetName)" "$(TargetExt)" "$(Configuration)"

I want you to understand that I have no control of these macro's $(ProjectDir) ... VS will fill these in.

To simplify things I've eliminated VS. Here is a script that simply echo's the input given to it. This will show the problem copy the below script to a file called echo-args.ps1
#===================================
"The number of parameters passed in is $($Args.Count)"
$i = 0
foreach ($arg in $Args) { echo "The $i parameter is $arg"; $i++ }
#===================================

Whether the script is invoked as

## works as expected
1) & "$env:SampleDir\echo-args.ps1" "D:\Users\robertla\Documents\Visual Studio 2017\Samples\Debug_Utilities\" "Debug Utilities" ".dll" "Debug"

or the below invocation which is how it needs to be invoked inside of the VS Post-Build event environment
## doesn't handle spaces correctly
2) powershell -ExecutionPolicy remotesigned -File "$env:SampleDir\echo-args.ps1" "D:\Users\robertla\Documents\Visual Studio 2017\Samples\Debug_Utilities\" "Debug Utilities" ".dll" "Debug"

This is the output from 2) which you can see is incorrect
The number of parameters passed in is 2
The 0 parameter is D:\Users\robertla\Documents\Visual Studio 2017\Samples\Debug_Utilities" Debug
The 1 parameter is Utilities .dll Debug

I wanted to show you that the output of 1) is not the same as the output of 2). However VS will spawn CMD.EXE and pass in the command line provided in the Post-Build event. This test really needs to be done in NT's shell.

Replace $env:SampleDir with %SampleDir% and rerun the 2) in CMD.EXE.

You should also checkout the behavior when single quotes are used rather than double quotes. Both are incorrect but in different ways

Hello, I have noticed some strange behavior with Powershell when run in a remote session, it seems as if there is a memory leak with write-progress when run in a remote session.

Take the following code for example:

$MaxVal = 10000000

for ($x=1;$x -le $MaxVal;$x++)
{
Write-Progress -Activity "Writing a progress event" -PercentComplete ($x / $MaxVal * 100) -Status "$($x / $MaxVal * 100)% complete"
}

If I run this locally, powershell.exe runs normally and does not take up much memory.

However, if I run it on the same computer from a remote session (as in, I do an enter-psesssion -computername computer).

The memory on powershell.exe keeps going up until it eventually crashes the process.

Is there something I am doing wrong or is this a bug within powershell? I noticed it because I have a long running script that I use write-progress in and it was running fine whenever it runs locally, but calling it in a powershell session kept hanging the script and it would never complete. If I just remove all the calls to write-progress from the script, it runs fine in a remote session.

Hi there

I've never used the powershell very much. Today I discovered this graphical bug in the rendering of the console text output:
https://i.imgur.com/H40F15W.png
This bug was very confusing at first. Then it just kept getting more irritating.
The bug appears when I scroll up and down, at the bottom of the window. Sometimes text gets cut off at the sides too, but only if I change the window width.
I think I remember I had similiar issues years ago on a different computer.

I couldn't find anything related on google. Maybe I used the wrong search terms?

Although totally unrelated: Please unblock icw-mss setting in tcp for atleast one profile. (Doesn't hurt to keep pressing this)

I've tried putting my commands in an exe module, but could not get this module loaded in PowerShell.

1) If I try to load my module as-is, e.g. an .exe file I get "The extension '.exe' is not a valid module extension. "

2) If I create a .psd1 manifest and put RootModule = 'MyModule.exe' there I get Object reference not set to an instance of an object.
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleNamedInManifest(PSModuleInfo parentModule, ModuleSpecification moduleSpecification, String moduleBase, Boolean searchModulePath, String prefix, SessionState ss, ImportModuleOptions options, ManifestProcessingFlags manifestProcessingFlags, Boolean loadTypesFiles, Boolean loadFormatFiles, Object privateData, Boolean& found, String shortModuleName, Nullable`1 manifestLanguageMode)
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors)
at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(PSModuleInfo parentModule, String fileName, String moduleBase, String prefix, SessionState ss, Object privateData, ImportModuleOptions& options, ManifestProcessingFlags manifestProcessingFlags, Boolean& found, Boolean& moduleFileFound)
at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName(ImportModuleOptions importModuleOptions, String name)
at Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()

Only Parallel, Queue, and IgnoreNew are supported right now. One would expect that the option available from the Task Scheduler GUI would be available in the powershell interface.

Steps to reproduce

$a = New-ScheduledTaskSettingsSet -MultipleInstances StopExisting

Expected behavior

The task's multiple instances policy is set to kill existing tasks before starting another instance.
Actual behavior

value "StopExisting" to type "Microsoft.PowerShell.Cmdletization.GeneratedTypes.ScheduledTask.MultipleInstancesEnum".
Error: "Unable to match the identifier name StopExisting to a valid enumerator name. Specify one of the following
enumerator names and try again:
Parallel, Queue, IgnoreNew"
At line:1 char:131
+ ... ngOnBatteries -ExecutionTimeLimit $b -MultipleInstances StopExisting
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [New-ScheduledTaskSettingsSet], ParameterBindingArgumentTransformationE
xception
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,New-ScheduledTaskSettingsSet

According to this question on stackoverflow, it has been reported, but Microsoft Connect no longer is alive, so I couldn't follow the bug. Google searching powershell bug report brought me here, not sure if it's the right place though.