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

Votes from Connect: 3

Original Date Submitted: 6/8/2015 2:40:45 PM

Description:
********Contact Information********
Handle: aL3891
Site Name: PowerShell
Feedback ID: 1411231
***************************************

Problem Description:
At the moment all dsc resources are executed serially. given that dependencies are allready specified, it would in theory be safe to execute steps in parallel.

I'm guessing this is planned at some point but i could really use a way to enable parallel execution because I'm using dsc to spin up test environments with a bunch of services and having those being set up in parallel would speed things up considerably.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1411231 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1411231).

Repro Steps:

Internal BugId: 14550

Votes from Connect: 11

Original Date Submitted: 2/6/2013 3:35:55 AM

Description:

********Contact Information********
Handle: DougBB
Site Name: PowerShell
Feedback ID: 778597
***************************************

Frequency: Always Happens
Regression: No, this is new to the most recent version

Problem Description:
Under certain circumstances, when Write-Progress is used in Windows PowerShell ISE and a new tab is opened, the Write-Progress output does not display properly. Closing tabs makes it appear.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 778597 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=778597).

Repro Steps:
1. Run "powershell_ise.exe -noprofile"
2. Paste the following code in the script pane:
$i = 1..100
$i | % {
write-progress -Activity "Testing Output" -Status $_ -PercentComplete $_
sleep 1
}
3. Note the progress bar works properly
4. Open a new tab by pressing Ctrl+T
5. Switch back to the first tab
6. Note the progress bar continues to works properly
7. Close the second tab
8. Open a new tab by pressing Ctrl+T
9. Switch back to the first tab and note the progress bar is missing
10. Close the third tab
11. Note that the progress bar displays properly again

Expected Results:
The progress bar from Write-Progress is displayed regardless of the state of the tabs in the ISE.

Internal BugId: 4106

I am unable to authenticate with a client certificate generated from OpenSSL or New-SelfSignedCertificate from a Windows 10 or 2012R2 powershell remoting client (likely broken in 8.1 but I did not test). I receive the following error:

new-PSSession : The WinRM client cannot process the request. If you are using a machine certificate, it must contain a DNS name in the Subject Alternative Name extension or in the Subject Name field, and no UPN name. If you are using a user certificate, the Subject Alternative Name extension must contain a UPN name and must not contain a DNS name. Change the certificate structure and try the request again.

The UPN is correctly specified in the SAN and there is no DNS entry.

I CAN authenticate with the same certificates from windows 7 or 2008R2 and I can also authenticate from windows 10/2012R2 if I use the ruby or python winrm libraries.

I checked the binary contents of both an ADCS gernerated cert and an OpenSSL one and my SAN contents are binary identical.

Please see http://www.hurryupandwait.io/blog/certificate-password-less-based-authentication-in-winrm for more details

NuGet feeds allow security around both listing/retrieving packages as well as pushing packages. NuGet.exe and other clients further allow you to persist credentials for listing/retrieving packages using the "nuget sources" command. (https://docs.nuget.org/consume/command-line-reference#sources-command)

This persistence is important for two reasons:

1) When you push a package to a secured NuGet feed, NuGet clients generally do a list/read operation first. That list/read operation doesn't contain any API key that you pass along in the push operation. In order for a push to succeed with an API key, you also need to have credentials set for the read operation. You can read about some folks who have been affected by that here: http://inedo.com/support/questions/2319

2) In an unattended/build server scenario, you need the ability to provide credentials for list/read and push in a non-interactive way. If the only way to provide credentials is interactive (e.g., Get-Credential) then there's no way to, say, enable a build server agent to automatically install required scripts to execute a build.

This may somewhat overlap with this other note about Register-PSRepository failing against authenticated endpoints: http://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11678499-register-psrepository-fails-against-authenticated

Votes from Connect: 42

Original Date Submitted: 4/10/2015 11:19:28 PM

Description:
********Contact Information********
Handle: Trevor Sullivan [MVP]
Site Name: PowerShell
Feedback ID: 1238786
***************************************

Problem Description:
The Out-GridView command displays all of the properties of each object that is fed into it. Consequently, in order to make the tool more usable, the Select-Object command can be used to inclusively filter the key properties of each object, to display to the end user. Unfortunately, this process results in a modified object, that cannot be used for all intended purposes.

Instead of using Select-Object, a -DisplayProperty parameter should be added to Out-GridView, so that unmodified objects can be piped into it, while only the specified properties are displayed. The pipeline output from Out-GridView should emit the unmodified objects.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1238786 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1238786).

Repro Steps:

Internal BugId: 14376

Votes from Connect: 12

Original Date Submitted: 4/4/2015 8:50:49 AM

Description:
********Contact Information********
Handle: Arnoud Jansveld
Site Name: PowerShell
Feedback ID: 1224213
***************************************

Frequency: PowerShell ISE
Regression: function Show-Form
{
[reflection.assembly]::LoadWithPartialName("System.Windows.Forms") >$null
$form = New-Object System.Windows.Forms.Form
$label = New-Object System.Windows.Forms.Label
$label.Text = "Please close this form"
$label.AutoSize = $true
$form.Controls.Add($label)
$form.ShowDialog()
}

$result = Show-Form

# Workaround (slow):
# $result = Start-Job ${function:Show-Form} | Receive-Job -Wait -AutoRemoveJob

"Form result: " + $result.ToString()

Write-Warning "The following step may hang PowerShell ISE, save your work!"
Read-Host -Prompt "Hit Enter or Ctrl-C to abort"

# This generates a WM_SETTINGCHANGE broadcast message
[Environment]::SetEnvironmentVariable("foo", "bar", "User")

Problem Description:
After using ShowDialog() to display a Windows Forms dialog, the ISE will hang when it receives a WM_SETTINGCHANGE broadcast message (e.g. when changing display resolution, switching from a laptop screen to an external monitor or connecting to the current session from another machine via RDP).

This was reproduced on PowerShell ISE version 4 and 5 (Feb preview). Sadly it affects many useful scripts, including Lee Holmes' (awesome) Show-Object.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1224213 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1224213).

Repro Steps:
function Show-Form
{
[reflection.assembly]::LoadWithPartialName("System.Windows.Forms") >$null
$form = New-Object System.Windows.Forms.Form
$label = New-Object System.Windows.Forms.Label
$label.Text = "Please close this form"
$label.AutoSize = $true
$form.Controls.Add($label)
$form.ShowDialog()
}

$result = Show-Form

# Workaround (slow):
# $result = Start-Job ${function:Show-Form} | Receive-Job -Wait -AutoRemoveJob

"Form result: " + $result.ToString()

Write-Warning "The following step may hang PowerShell ISE, save your work!"
Read-Host -Prompt "Hit Enter or Ctrl-C to abort"

# This generates a WM_SETTINGCHANGE broadcast message
[Environment]::SetEnvironmentVariable("foo", "bar", "User")

Expected Results:
The script should show an empty dialog; after closing it and hitting Enter at the prompt the ISE should remain responsive (on some occasions the script has to be run more than once for the problem to occur).

This works fine in the regular PowerShell console.

Internal BugId: 14363

Managing registry keys and values on local and remote systems with PowerShell is a pain.

Reviewing the articles, forums and blogs on the Internet clearly shows that new PowerShell users struggle to understand how to use registry provider drives and the cmdlets like New-Item, Get-ItemProperty, New-ItemProperty, and so on. This has prompted the creation of a variety of home-brew modules and functions to deal with the problem, like this one, which is extremely useful, but is not built into PowerShell by default of course:

https://gallery.technet.microsoft.com/RegistryLibrarypsm1-b38a81ba

PowerShell needs a proper set of built-in, dedicated registry cmdlets that 1) are easy to understand and use, even by PoSh newbies, 2) work on both local and remote registries, 3) can handle default values in keys, 4) can create the entire subkey path to a target value in one shot, 5) can create and set a value in one shot, 6) can handle all registry value types, including REG_BINARY, 7) export and import entire branches, 8) query and edit registry key permissions, and 9) which handle problems somewhat gracefully in a way that does not always require coders to write a bunch of tests or Try{}Catch{} constructs.

In general, just as we need a PowerShell version of ROBOCOPY.EXE, we need a PowerShell replacement for everything REG.EXE can do (and more).

For remote registry access, it would be nice to have support for both WSMAN and RPC, but RPC at a minimum (for those who don't configure WinRM/WSMAN on client devices). These registry cmdlets also need a -Credential parameter for connecting to stand-alone boxes in a workgroup that only have local accounts.

It's not enough to just have a nice registry module in the PSGallery, it needs to be built in so that we can rely on it everywhere; for example, these new registry cmdlets should ideally work on Linux or Mac OS machines using PowerShell to access the registry on remote Windows boxes.

REG.EXE is not good enough either: it's not object-oriented, does not support tab completion, does not support -WhatIf or -Verbose or -Recurse, etc. Same for ROBOCOPY.EXE.

And having just a DSC resource module is not good enough either. DSC is too complex or heavyweight for many organizations or scenarios.

Adding new registry cmdlets would not break any existing scripts that modify the local registry. And depending on how the network registry access is implemented, might not require a particular minimum version of WMF/PowerShell at the remote system either (though it may require WinRM to be configured).

Just as others have proposed or written functions for already, the names of the cmdlets might be like:

Get-RegistryValue
Set-RegistryValue
New-RegistryKey
Remove-RegistryValue
Remove-RegistryKey
Export-RegistryKey
Import-RegistryKey
And so on...

As others have already done, the cmdlets might just be wrappers for existing cmdlets, providers, classes or modules, which would be just fine, but they need to be built-in by default in the next version of WMF/PowerShell.

The above suggestion is not new and definitely not my idea, but I was hoping a new post in UserVoice would help to spark discussion about what is (not) needed and attract enough votes to get the ball rolling before the next version of WMF/PowerShell gets feature-locked.

Thanks,
Jason

Votes from Connect: 33

Original Date Submitted: 6/20/2013 11:48:19 PM

Description:
********Contact Information********
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 790578
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
It would be great if PS ISE had the ability to allow you to save and restore all of your open tabs and files. Ideally, there would be an option to automatically save the session when ISE is closed, and automatically load it when ISE is started.

The PowerShell Team has blogged about how to save/load your session by writing an add-on (http://blogs.msdn.com/b/powershell/archive/2010/06/05/export-and-import-powershell-ise-opened-files.aspx), and I have blogged about how to automatically load the session when ISE starts using their solution (http://blog.danskingdom.com/powershell-ise-multiline-comment-and-uncomment-done-right-and-other-ise-gui-must-haves/), but it would be great if this functionality was provided out of the box.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 790578 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=790578).

Repro Steps:
Open some files in PS ISE and then close ISE. When you open ISE again the tabs and files that you had open will not be automatically opened. You will need to go open each file again.

Expected Results:
When opening ISE any tabs and files that you had open previously should be restored.

Internal BugId: 4258

Type: Feature Request
Summary: Make LCM extensible simply by adding a psm1 in a folder, which will be loaded automatically.
Details here: https://github.com/gaelcolas/LCM_ExtensibleArch

Here's the workflow:
1. LCM loads a psm1 file(s) from a pre-defined directory (or defined in LCM meta-configuration).
2. Every LCM events are triggered and forwarded into the extensions' session
3. $Global variables of the extension should be accessible from the Test/Set/Get methods of the DSC Resource
3. The author of the PSM1 extension register-EngineEvent for required LCM Events
4. He defines Event Handlers Actions that can call psm1's exported functions

Having this extensible architecture would allow us to complement the LCM features.

I've created an illustration of such PSM1 extension here: https://github.com/gaelcolas/LCM_ExtensibleArch/blob/master/LCMExtension.psm1

Event better: having a class we can 'decorate' so that we can tap directly into the LCM handling, or rely on the default handler.

Votes from Connect: 3

Original Date Submitted: 10/30/2014 5:41:25 PM

Description:
********Contact Information********
Handle: ulrichb
Site Name: PowerShell
Feedback ID: 1015225
***************************************

Frequency: Always Happens
Regression: Yes, this happens in all previous versions

Problem Description:
New-ScheduledTaskTrigger offers just a subset of the trigger options. Things like "On an (event log) event", or "On workstation (un)lock" are missing.

We just found ugly workarounds to add these (e.g. event log) triggers by using "schtasks.exe /create /xml" or using the COM "TaskScheduler" class.

New-ScheduledTaskTrigger should allow specifying all options the Task Scheduler UI offers. As there already exists an XML representation of these triggers (e.g. <EventTrigger>, <SessionStateChangeTrigger>, ...) it would also be possible to offer a "-Custom" parameter which takes such an XML fragment to specify a trigger.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 1015225 (http://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=1015225).

Repro Steps:
Expected Results:

Internal BugId: 13076