Problem Description
------------------
If you are using the `using module` statement, it will load the module without any issues. However, if you make a change to the module and run the `using module` statement again without restarting your PowerShell session, it will not load the new modified module into memory, and instead will continue to use the old existing module that was loaded. This makes doing development with `using module` statements very tedious as you must continually reload your PowerShell session whenever you make changes to the module.

Ideally we would just use `Import-Module -Name [module name] -Force` to avoid this issue, but that does not work for importing `class`es, so the `using module` statement **must** be used.

Steps to reproduce
------------------
Create the following module and script files:

In `TestModule.psm1`:
```powershell
class TestClass
{
[string] $ClassPropertyText = "Initial text"
}

function Get-ModuleFunctionText()
{
return "Initial text"
}

Export-ModuleMember -Function Get-ModuleFunctionText
```

In `Test.ps1`:
```powershell
using module '.\TestModule.psm1'

$instance = [TestClass]::new()
$instance.ClassPropertyText

Get-ModuleFunctionText
```

Run `Test.ps1` and it will output:
```
Initial text
Initial text
```

Then modify `TestModule.psm1` to:
```powershell
class TestClass
{
[string] $ClassPropertyText = "Updated text"
}

function Get-ModuleFunctionText()
{
return "Updated text"
}

Export-ModuleMember -Function Get-ModuleFunctionText
```

Run `Test.ps1` again and it will still output:
```
Initial text
Initial text
```

Expected behavior
-----------------
When running `Test.ps1` the 2nd time, it should output:
```none
Updated text
Updated text
```

Environment data
----------------

<!-- provide the output of $PSVersionTable -->

```powershell
> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.17134.228
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17134.228
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
```

Additional Info
----------------
The problem can be somewhat reduced by using _both_ the `using module` statement and `Import-Module -Force` statement, like this:
```powershell
using module '.\TestModule.psm1'
Import-Module -Name '.\TestModule.psm1' -Force

$instance = [TestClass]::new()
$instance.ClassPropertyText

Get-ModuleFunctionText
```

This code would result in the following output:
```
Initial text
Updated text
```

So here the module code was updated, but the `class` code was not.

Proposed Solution
----------------
To fix this issue I propose adding a `-Force` flag to the `using module` statement that forces the module to be reloaded into memory; the same way that the `-Force` flag works for the `Import-Module` cmdlet. This will allow developing code that uses the `class` construct to work much smoother.

I also proposed this same change to PowerShell Core at: https://github.com/PowerShell/PowerShell/issues/7654

Hi Team,

I am using powershell to trigger commands on remote machine (as this doesn't require anything additional package to install). Recently I am facing issues with running commands on remote machine.

$ComputerName = "***.***.***.***"

Function ExecuteCommand() {
Get-PSDrive
}

Set-Item WSMan:\localhost\Client\Trustedhosts -Value $ComputerName -Concatenate -Force

$Credentials = Import-Clixml $CredentialsFile

Invoke-Command -ComputerName $ComputerName -Credential $Credentials -ScriptBlock ${function:ExecuteCommand} -HideComputerName

I am storing the credentials in the file and using the above script to run commands on remote machine.

1. Get-PSDrive doesn't return mapped network drive details.
2. using net use command to map network path. Network path gets mapped successfully but the status of the mapped network path is unavailable. This was working properly around 1 and half month ago but not sure what changed in past 1 and half month.

I am using
OS: Windows Server 2012 r2
Powershell 4.0
PSRemotingProtocolVersion 2.2

Can someone please help here?

Thanks.

The following script demonstrates an issue I'm experiencing after moving from PowerShell v4 to v5.1. I make extensive use of Start-Process redirecting StandardError to a file, if this file contains data after execution I can read the file to see what the issue was.

However, with v5.1 when the launched PowerShell process starts, it makes use of progress output which is on the error stream, so this is redirected to the error file.

In previous versions of PowerShell this did not happen.

The output to the script below is as follows:

Powershell v4
------------------
WARNING: Standard Error
WARNING: Standard Out
hello world!

Powershell v5.1
---------------------
WARNING: Standard Error

SourceId Record
-------- ------
1 parent = -1 id = 0 act = Preparing modules for first use. stat = cur = pct = -1 sec = -1 type = Completed
hello world!

WARNING: Standard Out
hello world!

# ------------------------------------- Script Start

$outfile = [System.IO.Path]::GetTempFileName()
$errorfile = [System.IO.Path]::GetTempFileName()

$command = "write-host 'hello world!'"
$encodedCommand = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($command))
$argumentList = @(
"-NoLogo",
"-NonInteractive",
"-NoProfile",
"-EncodedCommand",
$encodedCommand
)

Start-Process powershell `
-argumentlist $argumentList `
-PassThru `
-wait `
-RedirectStandardOut $outfile `
-NoNewWindow `
-RedirectStandardError $errorfile | Out-Null

Write-Warning "Standard Error"
try {
Import-Clixml $errorfile | Out-Host
}
catch {
Get-Content $errorfile
}

Write-Warning "Standard Out"
Get-Content $outfile

$outfile, $errorfile | Remove-item

Three folders; d1, d2, d3, with files test.txt and test.mp3 in in d1 and d3.

'-Include *d1*' includes only content from d1. Would expect '-Exclude *d1*' to include the inverse, but it has no effect, it returns all data.

unless it's run after -Include.

So '-Include *d1* -Exclude *d1*' returns nothing, as expected.

Exclude only works as it applies to a file name, not a path.

So '-Exclude *.txt' will exclude all files '*.txt' as expected.

The syntax usage in the help file is identical for both parameters.

Please fix -Exclude parameter so that it works on the Path consistently, as the documentation states it should.

admit it, PS is ugly. with the multitudes of loops we have to jump thru to get a desired result, it would be better if you could provide command line switches for common tasks.

for example, in a select statement, how do you prevent the header from appearing in the output? would be nice if could just do "select -NoHeader …." but you can't.

that is just one example where I spent 30 minutes looking for a way to display only without headers in a "select" statement. a lot of our searches involves either an object has or has not so it would really be appreciated if those "has or has not" could be simplified into command line switches as mentioned above.

just image if "Export-CSV" does not have a switche "-NoTypeInformation" and you'll know exactly what the problem is.

Let's take this simple loop:

PS C:\temp> for ($a=0; $a -lt 2; $a++ ) {
>> get-date;
>> Write-Host "Hello world!";
>> Get-ChildItem | ft -a;
>> sleep 1
>> }

18 juillet 2018 14:54:47
Hello world!

Directory: C:\temp

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2018-07-18 14:49 3698 test.txt

Hello world!
18 juillet 2018 14:54:48

Directory: C:\temp

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2018-07-18 14:49 3698 test.txt

As you can see, "Get-Date" and "Hello world!" gets inverted.

If we remove "ft -a" everything is executed as it should.

Using While ($true) { ... } does the exact same thing.

Tested on Powershell 4 and 5 on fully upgraded machines.

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