Votes from Connect: 17

Original Date Submitted: 6/21/2013 12:41:41 AM

Description:
Contact Information
Handle: deadlydog
Site Name: PowerShell
Feedback ID: 790585

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

Problem Description:
It would be nice in PS ISE if when you have multiple files open, that you could drag the tabs at the top of the Script Pane window (i.e. the file names) to rearrange them. Right now if you want to rearrange the order of the tabs, you have to actually close the tabs and re-open them in the order that you want them.

This is a standard feature in most tabbed editors.

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

Repro Steps:
Open multiple files in the PS ISE Script Pane. Use the mouse to try and drag one tab to the left/right of another tab; nothing happens.

Expected Results:
Open multiple files in the PS ISE Script Pane. Use the mouse to try and drag one tab to the left/right of another tab; the tab should move to where it is being dragged.

Internal BugId: 4262

Install-PackageProvider cannot retrieve the list of available providers if the machine doesn't have direct access to the internet.

PS C:\Windows\system32> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
WARNING: Unable to download the list of available providers. Check your internet connection.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package
provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac

kageProvider], Exception

+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro

vider

How to reproduce:
1. Setup a network completely separate from the internet.
2. Setup an HTTP-proxy in that network as following:
2.1. The machine with HTTP-proxy has 2 network interfaces: 1 connected to a LAN and another one - to the internet.
2.2. Configure the proxy in a way to require authentication, not allowing anonymous connections. Configure Kerberos authentication.
2.3. Allow access to the internet via the proxy for AD user accounts only, not for the computer ones.
3. Publish the proxy with WPAD.
4. Use Group Policy to configure Internet Explorer throughout the network to use WPAD as a source of proxy settings.
5. Try access the internet (http://example.com) via Internet Explorer - everything works fine.
6. Launch PowerShell console as an administrator, using AD account allowed to access internet via the proxy.
7. Try to download NuGet provider using Install-PackageProvider cmdlet - you receive an error shown above.

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 classes, 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

As a part of infrastructure as code or using DSC in the deployment pipelines, it is desired that we be able to identify the version of the node configuration. With all configurations being put into a source / version control repository, it won't be difficult to promote the version number for a given configuration document. However, at this point in time, there is no way to specify the version of the configuration document itself anywhere. This makes it hard to determine or identify what version of the configuration is being used on a target node without using a 3rd party console or integration into source control.

The ask here is to add support for specifying configuration meta properties such as version of the configuration.

Object Oriented Programming seems to be supported now in PowerShell, but custom classes defined in modules don't seem to behave the way they should.

There only seem to be two consistent ways to make these work when importing a module that has classes defined:
1. Import the module, then run "using module ..." to make the classes available in the session. Alternatively, you can import the module with the using statement, but this isn't ideal (no versioning).
2. Add the class definition file(s) to the ScriptsToProcess attribute of the module. This isn't ideal either as it runs the scripts in the global session which is bad practice.

Please provide a method that allows classes to be packaged with a module to support OOP scenarios. Thanks!

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