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

Currently module imports initiated via the RequiredModules statement in a Module Manifest do not allow for verbosity preference.

This results in a lot of additional noise for end users.
For example. If a DSC Resource module requires other modules, and imports them via RequiredModules in the Module Manifest then the following happens:

If an end-user is attempting to troubleshoot their DSC configuration they will utilize

Start-DscConfiguration -UseExisting -Verbose -Force

The results will be a verbose line for every cmdlet imported/exported from every included module. Which is A LOT of noise surrounding the verbose messages actually relevant to the end user.

There should be a way to avoid this. Something like this:

RequiredModules = @(@{ModuleName = "MSOnline"; ModuleVersion = "1.1.183.17"; Verbose:$false })

I have a filter in a script module that a does a little error formatting and flags the fact that it's seen an error. Most of the time, it seems to do its little job just fine. About once a week a sharing violation triggers some kind of infinite recursion and PowerShell emits the depth overflow error. The odd thing is that the function is not recursive. I've run procmon and I can see that the sharing violation happens just once - most of what happens after than is PowerShell writing to a pstrace log (I've wrapped the offending section in Trace-Command *). I can supply the .PML from procmon and the pstrace file, both for a failing instance and for a successful run 2 minutes later.

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()

Hi there

Im working with WindowsPE and have to identify my USB-Drive.

So I´m looking for the drive and assign a variable:

$usb_drive = (Get-WmiObject -class Win32_LogicalDisk -filter DriveType=2 | Foreach {Get-ChildItem -Filter *.wim -r -d 1 $_.DeviceID} 2>$null | Where {$_.name -eq "boot.wim"}).PsDrive.Root

With Powershell 5.1.14393.2791 its working as expected. With 5.1.18361.1 not.

The reason is this part:

Get-WmiObject -class Win32_LogicalDisk -filter DriveType=2 | Foreach {Get-ChildItem -Filter *.wim -r -d 1 $_.DeviceID}

The Reason is handling of $_.Deviceid. On both versions the Result is c:

On both versions Get-Childitem C: gets the entries of the local directory (which makes absolutely no sense!!!!)
Get-Childitem c:\ gets the root-entries form c: - which makes sense.

However - the code postet here works on 14393, but not on 18361.1

imho it should

Write-Information does not show in a file transcribed by Start-Transcript unless you set $InformationPreference to 'SilentlyContinue'... which then means it does not display in the console.

I believe this is a bug in Windows PowerShell (as of v5.1.17134.590) that has been fixed in PowerShell Core? If we cannot go to Core I have to do some workarounds (like using Write-Host or creating a function that combines 2 Write-Information calls with different preferences).

There looks like a better formatted thread here on this issue:
https://stackoverflow.com/questions/55191548/write-information-does-not-show-in-a-file-transcribed-by-start-transcript

Here's $PSVersionTable:
---------------------------------------------------------------------------
PSVersion 5.1.17763.316
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.316
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

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).