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

Problem:

When creating an object from the x509Certificate class the shell adds 3 script properties:

DnsNameList
EnhancedKeyUsageList
SendAsTrustedIssuer

The SendAsTrustedIssuer property causes Powershell to hit a CLR exception and hard crash when accessed.

Repro Code:

* Note: do this in a fresh session as it will crash the session

$Test = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2
$Test | select *

Alternately,

$Test = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2
$Test.SendAsTrustedIssuer

Crash dump:

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Management.Automation.Security.NativeMethods.CertGetCertificateContextProperty(IntPtr pCertContext, CertPropertyId dwPropId, IntPtr pvData, Int32& pcbData)
at Microsoft.PowerShell.Commands.SendAsTrustedIssuerProperty.ReadSendAsTrustedIssuerProperty(X509Certificate2 cert)
at CallSite.Target(Closure , CallSite , Type , Object )
at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)
at System.Management.Automation.Interpreter.DynamicInstruction`3.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
at System.Management.Automation.ScriptBlock.InvokeWithPipeImpl(ScriptBlockClauseToInvoke clauseToInvoke, Boolean createLocalScope, Dictionary`2 functionsToDefine, List`1 variablesToDefine, ErrorHandlingBehavior errorHandlingBehavior, Object dollarUnder, Object input, Object scriptThis, Pipe outputPipe, InvocationInfo invocationInfo, Object[] args)
at System.Management.Automation.ScriptBlock.<>c__DisplayClass57_0.<InvokeWithPipe>b__0()
at System.Management.Automation.Runspaces.RunspaceBase.RunActionIfNoRunningPipelinesWithThreadCheck(Action action)
at System.Management.Automation.ScriptBlock.InvokeWithPipe(Boolean useLocalScope, ErrorHandlingBehavior errorHandlingBehavior, Object dollarUnder, Object input, Object scriptThis, Pipe outputPipe, InvocationInfo invocationInfo, Boolean propagateAllExceptionsToTop, List`1 variablesToDefine, Dictionary`2 functionsToDefine, Object[] args)
at System.Management.Automation.ScriptBlock.DoInvokeReturnAsIs(Boolean useLocalScope, ErrorHandlingBehavior errorHandlingBehavior, Object dollarUnder, Object input, Object scriptThis, Object[] args)
at System.Management.Automation.PSScriptProperty.InvokeGetter(Object scriptThis)
at Microsoft.PowerShell.Commands.Internal.Format.MshExpression.GetValue(PSObject target, Boolean eatExceptions)
at Microsoft.PowerShell.Commands.Internal.Format.MshExpression.GetValues(PSObject target, Boolean expand, Boolean eatExceptions)
at Microsoft.PowerShell.Commands.SelectObjectCommand.ProcessParameter(MshParameter p, PSObject inputObject, List`1 result)
at Microsoft.PowerShell.Commands.SelectObjectCommand.ProcessObject(PSObject inputObject)
at Microsoft.PowerShell.Commands.SelectObjectCommand.ProcessObjectAndHandleErrors(PSObject pso)
at Microsoft.PowerShell.Commands.SelectObjectCommand.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
at System.Management.Automation.CommandProcessorBase.DoExecute()
at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.Interpreter.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.LightLambda.RunVoid1[T0](T0 arg0)
at System.Management.Automation.DlrScriptCommandProcessor.RunClause(Action`1 clause, Object dollarUnderbar, Object inputToProcess)
at System.Management.Automation.DlrScriptCommandProcessor.Complete()
at System.Management.Automation.CommandProcessorBase.DoComplete()
at System.Management.Automation.Internal.PipelineProcessor.DoCompleteCore(CommandProcessorBase commandRequestingUpstreamCommandsToStop)
at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input)
at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()
at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
at System.Management.Automation.Runspaces.PipelineThread.WorkerProc()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()

I created a runbook on several automation accounts that move around files and folders on Datalake Storage Accounts (gen 1). The runbook works without hitches on 2 automation accounts, but did not work on the other 2.

There were quite a few differences in the versions of the added modules: the runbook worked on the older versions of the modules, but not the newer. Specifically the cmdlet Move-AzureRmDataLakeStoreItem threw an error on the newer versions:
"Account name ***.azuredatalakestore.net/ is invalid. Specify the full account including the domain name."

After trying quite a few iterations of writing the account name (just the name, "***", as it should be according to documentation; "***.datalakestore.net/"; "adl://***.datalakestore.net";...), I finally reverted the modules to older versions, which solved the problem. I would assume the issues arises from the AzureRM.DataLakeStore module, given that the cmdlet resides there, but I'm not entirely sure (I reverted all modules).

Example:

$Get-Process | select -First 5 | ft -au

Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
716 47 32832 43396 587 1764 AdminManagerClient
257 34 3432 9352 84 1128 AgentService
495 78 15700 28528 154 3744 AppVClient
244 35 60952 41796 692 0.56 5416 AppVStreamingUX
591 18 17280 22992 108 1,751.98 4672 audiodg

$Get-Process | select -First 5 | ft -markdown

|Handles|NPM(K)|PM(K)|WS(K)|VM(M)| CPU(s)| Id|ProcessName |
|-------|------|-----|-----|-----|--------|----|------------------|
| 716| 47|32832|43396| 587| |1764|AdminManagerClient|
| 257| 34| 3432| 9352| 84| |1128|AgentService |
| 495| 78|15700|28528| 154| |3744|AppVClient |
| 244| 35|60952|41796| 692| 0.56|5416|AppVStreamingUX |
| 591| 18|17280|22992| 108|1,751.98|4672|audiodg |

This could be pasted to a morkdown file and would be nicely rendered as a table.

The Other way to read tables from markdown woulb de nice to. It would require a syntax for naming tables and referencing them in markdown. It would allow very readable configuration files.

(Sorry here is no monospace font available)

In WMF5, if the PSModulePath environment variable has a UNC Path in it that is currently inaccessible, powershell fails to load many built-in modules.

For instance, if PSModulePath looks like this:

C:\Users\jmmurrah\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerShell\v1.0\Modules;\\badservername\folder

When powershell loads and times out trying to access the path, many standard cmdlets are not found; get-host, test-path, format-list, etc.

Get-member -listavailable reports back the modules, but does not list their path on disk, and many of them have no exported commands. When trying to import one of these modules powershell reports an error that the module path cannot be found.

This doesn't appear to happen with a bad local path, only with a network path.

Votes from Connect: 9

Original Date Submitted: 6/16/2015 3:12:31 AM

Description:
********Contact Information********
Handle: Ondrej Sevecek
Site Name: PowerShell
Feedback ID: 1437366
***************************************

Frequency: PowerShell
Regression: run the mentioned script on Windows 10.0.10074 in its built-in PowerShell 5.

Problem Description:
When I run the following on Windows 10.0.10074 in PowerShell 5, it does not work for user members of the local group:

$admins = [ADSI] 'WinNT://./Administrators,group'

foreach ($oneMember in $admins.Members()) {

$oneMemberName = $oneMember.GetType().InvokeMember('Name', 'GetProperty', $null, $oneMember, $null)
Write-Host $oneMemberName

}

The error is: Error while invoking GetType. Could not find member.

While the code works fine on any other OS (tested on Windows XP, Vista, 7, 8, 8.1) within PowerShell 2,3,4. It also works fine within PowerShell 2 on Windows 10.0.10074.

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

Repro Steps:
run the mentioned script on Windows 10.0.10074 in its built-in PowerShell 5.

Expected Results:
it should run well :-)

Internal BugId: 15570

Votes from Connect: 23

Original Date Submitted: 5/28/2015 11:09:44 PM

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

Problem Description:
In the spirit of splatting, a cool feature to have for PowerShell v5 or vNext, would be to be ale to splat method parameters on PowerShell classes.

Right now, an error message appears: "The splatting operator '@' cannot be used to reference variables in an expression. '@NewPerson' can be used only as an argument to a command. To reference variables in an expression use '$NewPerson'."

class Person {
[string] $FirstName;
[string] $LastName;

Person ([string] $First, [string] $Last) {
$this.FirstName = $First;
$this.LastName = $Last;
}
}

$NewPerson = @{
FirstName = 'Trevor';
LastName = 'Sullivan';
};
[Person]::new(@NewPerson);

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

Repro Steps:

Internal BugId: 14521

Votes from Connect: 10

Original Date Submitted: 12/10/2011 12:21:15 AM

Description:
********Contact Information********
Handle: JoshGav
Site Name: PowerShell
Feedback ID: 712796
***************************************

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

Problem Description:
The final delimiter in a here-string is defined as newline-quotemarks-atsign. This means that the "@ has to be at the beginning of the final line, with no whitespace preceding it. This ruins attempts at tab indentation in scripts and functions. Whitespace should be allowed as part of the ending pattern between the newline and quotemarks so that tab indentation can be cleanly utilized.

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

Repro Steps:
If a here-string is typed as follows:
$str = @"
a string
"@
it will not be evaluated properly.

Expected Results:
Allow the previously indicated string as a here-string, ignoring the extra whitespace between the final newline and ".

Internal BugId: 3186

Votes from Connect: 8

Original Date Submitted: 8/25/2015 10:53:08 AM

Description:
********Contact Information********
Handle: Joel 'Jaykul' Bennett
Site Name: PowerShell
Feedback ID: 1709557
***************************************

Frequency: PowerShell
Regression: Try to use a keyword as a method:

class Startup {
[void] Configuration([OWin.AppBuilder]$app)
{
$app.UseNancy()
}
}

class Test {
[hashtable]$Options
[void] Switch([string]$option)
{
$Options[$option] = !$Options[$option]
}
}

class Test {
[hashtable]$Options
[bool] If([string]$option)
{
return [bool]$Options[$option]
}
}

Problem Description:
We currently can't define methods or properties with names that match PowerShell keywords. This is silly, since we CAN define functions with those names -- and because of how you can use them, functions with keyword names can cause confusion, but class members cannot!

This is a problem because it prevents us from implementing interfaces or conventions which use these names.
For instance, we cannot do anything with OWin, because we need to implement a class with a "Configuration" method:

class Startup {
[void] Configuration([OWin.AppBuilder]$app)
{
$app.UseNancy()
}
}

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

Repro Steps:
Try to use a keyword as a method:

class Startup {
[void] Configuration([OWin.AppBuilder]$app)
{
$app.UseNancy()
}
}

class Test {
[hashtable]$Options
[void] Switch([string]$option)
{
$Options[$option] = !$Options[$option]
}
}

class Test {
[hashtable]$Options
[bool] If([string]$option)
{
return [bool]$Options[$option]
}
}

Expected Results:
There's no reason that PowerShell keywords should be reserved against class method names -- they're not even reserved against function names, where it can **actually** be confusing.

Internal BugId: 15755

PS > type .\error.ps1
[Cmdletbinding()]
param()

"hello"
"world"

1/0

PS > .\error.ps1
hello
world
Attempted to divide by zero.
At D:\junk\error.ps1:10 char:5
+ 1/0
+ ~~~
+ CategoryInfo : NotSpecified: (:) [], RuntimeException
+ FullyQualifiedErrorId : RuntimeException

PS > $ErrorActionPreference = "Stop"
PS > .\error.ps1
hello
world
D:\junk\error.ps1 : Attempted to divide by zero.
At line:1 char:1
+ .\error.ps1
+ ~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [error.ps1], RuntimeException
+ FullyQualifiedErrorId : RuntimeException,error.ps1

Note incorrect line number being reported on second invocation when ErrorActionPreference equals "Stop"

This can also be reproduced by putting "$ErrorActionPreference = "Stop" at line 3 of the script.

I always set ErrorActionPreference to Stop at the start of my scripts, and also have ErrorActionPreference set to "Stop" always in my environment for improved robustness as I write scripts, As a result this issue is very problematic. The correct line number can be obtained by digging into $Error but that is a pain.

This started happening somewhere around the v5 release. Prior to that the correct line number was always reported. This can also be reproduced by using -ErrorAction Stop at a particular invocation, although that is a less compelling scenario.

PSVersion 5.1.18272.1000