text:
7.4.0 Linux native shared libraries in module not loaded using the RID directory

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
I have powershell module that uses native shared libraries packaged in the module.
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/System.Data.SQLite.dll
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/osx-x64/SQLite.Interop.dll.dylib
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-arm/SQLite.Interop.dll.so
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-x64/SQLite.Interop.dll.so
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-arm64/SQLite.Interop.dll.so
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/win-x86/SQLite.Interop.dll.dll
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/osx-arm64/SQLite.Interop.dll.dylib
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/win-arm/SQLite.Interop.dll.dll
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/win-arm64/SQLite.Interop.dll.dll
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLiteConnection.dll
/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/win-x64/SQLite.Interop.dll.dll

7.3.10 finds and loads these shared libraries.
7.4.0 does not look for them on Linux under the RID directory
Expected behavior
3463:     file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.so [0];  dynamically loaded by /opt/microsoft/powershell/7/libcoreclr.so [0]
      3463:     file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.so [0];  dynamically loaded by /opt/microsoft/powershell/7/libcoreclr.so [0]
      3463:     opening file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-x64/SQLite.Interop.dll.so [0]; direct_opencount=25
      3463:     symbol=sqlite3_set_authorizer;  lookup in file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-x64/SQLite.Interop.dll.so [0]
      3463:     binding file /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-x64/SQLite.Interop.dll.so [0] to /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/linux-x64/SQLite.Interop.dll.so [0]: normal symbol `sqlite3_set_authorizer'

Actual behavior
3223:     file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.so [0];  dynamically loaded by /opt/microsoft/powershell/7/libcoreclr.so [0]
      3223:     file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.so [0];  dynamically loaded by /opt/microsoft/powershell/7/libcoreclr.so [0]
      3223:     file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.so [0];  dynamically loaded by /opt/microsoft/powershell/7/libcoreclr.so [0]
      3223:     file=/home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.so [0];  dynamically loaded by /opt/microsoft/powershell/7/libcoreclr.so [0]
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.so: cannot open shared object file: No such file or directory
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.so: cannot open shared object file: No such file or directory

Error details
     | Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies. In order to help diagnose loading
     | problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment
     | variable:  /opt/microsoft/powershell/7/SQLite.Interop.dll.so: cannot open shared object file: No such file or
     | directory
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.so:
     | cannot open shared object file: No such file or directory /opt/microsoft/powershell/7/libSQLite.Interop.dll.so:
     | cannot open shared object file: No such file or directory
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.so: cannot open shared object file: No such file or directory /opt/microsoft/powershell/7/SQLite.Interop.dll: cannot open shared object file: No such file or directory /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll: cannot open shared object file: No such file or directory /opt/microsoft/powershell/7/libSQLite.Interop.dll: cannot open shared object file: No such file or directory /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll: cannot open shared object file: No such file or directory

Environment data
Name                           Value
----                           -----
PSVersion                      7.4.0
PSEdition                      Core
GitCommitId                    7.4.0
OS                             Ubuntu 22.04.3 LTS
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals
Important detail -
Running the "test.ps1" from within a PowerShell 7.4.0 session works, but running "test.ps1" from a bash shell doesn't.

If I add a symbolic link within the module directory...
SQLite.Interop.dll.so -> linux-x64/SQLite.Interop.dll.so

Then it works, so it is not the build of the shared library itself that is the problem

Same error on OSX
% grep SQLite.Interop.dll.dylib out.2 | grep 1.0.118
     | dlopen(/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.dylib, 0x0001): tried:
     | '/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.dylib' (no such file),
     | '/System/Volumes/Preboot/Cryptexes/OS/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.dylib' (no such file),
     | '/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.dylib' (no such file) dlopen(SQLite.Interop.dll.dylib, 0x0001): tried: 'SQLite.Interop.dll.dylib' (no such file),
     | dlopen(/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.dylib, 0x0001): tried:
     | '/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.dylib' (no such file),
     | '/System/Volumes/Preboot/Cryptexes/OS/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.dylib' (no such file),
     | '/Users/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.dylib' (no such file) dlopen(libSQLite.Interop.dll.dylib, 0x0001): tried: 'libSQLite.Interop.dll.dylib' (no such file),

Again, if I create a symlink,
SQLite.Interop.dll.dylib -> osx-arm64/SQLite.Interop.dll.dylib

It works

Ah, I have found something peculiar
If I run my script within a powershell console session, then it works but if I run it from unix shell with the prefix..
$ head test.ps1
#!/usr/bin/env pwsh
#

Then it fails. So it looks like the process initialisation is different. But still 7.3.10 works and 7.4.0 fails.

In my case, a module from the home modules path ($env:PSModulePath) don't work either unless I load it manually using Import-Module.  Get-Command -Module <module> also loaded module.

Maybe try to export LD_LIBRARY_PATH to set path to home shared libraries? In ~/.profile:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/.config/powershell/Modules/your_dir

This is my scenario SQLiteConnection
Running the "test.ps1" from within a PowerShell 7.4.0 session works, but running "test.ps1" from a bash shell doesn't.
With PowerShell 7.3.10, running test.ps1 from bash worked.

@rhubarb-geek-nz The folder structure you have listed seems a bit unexpected to me. If the dep.json files are being used at all to the platform-specific dependencies, then all of those RID folders should be inside a runtimes folder.
The deployed folder structure should match the layout from the NuGet package, with the native subfolders, etc:

Yes, we found it out in Dependency on Native Libraries adds extra file extensions by using strace to find out how PowerShell was trying to load native shared libraries.
It is not the same layout as a NuGet library package.
Even though the dlls had the dll extension they needed an additional .so, .dll or .dylib
For core with win, osx and linux it is like that.
rhubarb-geek-nz.SQLiteConnection.nuspec
osx-arm64\SQLite.Interop.dll.dylib
win-arm64\SQLite.Interop.dll.dll
README.md
System.Data.SQLite.dll
osx-x64\SQLite.Interop.dll.dylib
win-x64\SQLite.Interop.dll.dll
linux-arm\SQLite.Interop.dll.so
win-arm\SQLite.Interop.dll.dll
win-x86\SQLite.Interop.dll.dll
rhubarb-geek-nz.SQLiteConnection.psd1
linux-arm64\SQLite.Interop.dll.so
SQLiteConnection.dll
linux-x64\SQLite.Interop.dll.so

It is simpler for desktop with only win, then then win prefix can be dropped and just keep the original dll extension
rhubarb-geek-nz.SQLiteConnection.Desktop.nuspec
x64\SQLite.Interop.dll
README.md
SQLiteConnection.dll
arm\SQLite.Interop.dll
x86\SQLite.Interop.dll
System.Data.SQLite.dll
arm64\SQLite.Interop.dll
rhubarb-geek-nz.SQLiteConnection.Desktop.psd1

It is not the same layout as a NuGet library package.

It really should be. If it's not, then I'd argue PowerShell is doing something wrong.

It really should be. If it's not, then I'd argue PowerShell is doing something wrong.

I think that boat has sailed! There is a whole PSGallery to support which is using what works!
My code has no custom loader and is using what PowerShell does 'out of the box'.

If I run my script within a powershell console session, then it works but if I run it from unix shell with the prefix..

Please update the OP with the repro fact.

$ head test.ps1
#!/usr/bin/env pwsh

Can you dump env variables in the script and in console.

$ head test.ps1
#!/usr/bin/env pwsh

Can you dump env variables in the script and in console.

Which variables do you need?
This is the git repository with the test.ps1. The repository is very small.
The rhubarb-geek-nz.SQLiteConnection module is in the PSGallery

@rhubarb-geek-nz I mean to put gci env: in the test script and see results.

Using Debian 11
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

With powershell from packages.microsoft.com
$ dpkg -l  powershell
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-==================================================================
ii  powershell     7.4.0-1.deb  amd64        PowerShell is an automation and configuration management platform.

Module is installed from PSGallery
$ pwsh -c "Get-Command New-SQLiteConnection"

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          New-SQLiteConnection                               1.0.118.0  rhubarb-geek-nz.SQLiteConnection

Get project
$ git clone https://github.com/rhubarb-geek-nz/SQLiteConnection.git SQLiteConnection-git

cd SQLiteConnection-git

edit to add "gci env:" to start of test.ps1
$ git diff
diff --git a/test.ps1 b/test.ps1
index 6aea750..473b5d3 100755
--- a/test.ps1
+++ b/test.ps1
@@ -23,6 +23,8 @@ param(
        $CommandText = 'SELECT * FROM MESSAGES'
 )

+gci env:
+
 $ErrorActionPreference = "Stop"

 trap

Run in interactive session
$ pwsh
PowerShell 7.4.0
PS /home/bythesea/SQLiteConnection-git> ./test.ps1

Name                           Value
----                           -----
_                              /usr/bin/pwsh
DOTNET_CLI_TELEMETRY_OPTOUT    true
HOME                           /home/bythesea
LANG                           en_GB.UTF-8
LOGNAME                        bythesea
LS_COLORS                      rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:…
MOTD_SHOWN                     pam
OLDPWD                         /home/bythesea
PATH                           /opt/microsoft/powershell/7:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
POWERSHELL_TELEMETRY_OPTOUT    true
POWERSHELL_UPDATECHECK         Off
PSModulePath                   /home/bythesea/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/powershell/7/Modules
PWD                            /home/bythesea/SQLiteConnection-git
SHELL                          /bin/bash
SHLVL                          1
SSH_CLIENT                     172.17.0.1 46240 22
SSH_CONNECTION                 172.17.0.1 46240 172.17.0.4 22
SSH_TTY                        /dev/pts/0
TERM                           xterm-256color
USER                           bythesea

CONTENT
-------
Hello World

Run directly from bash
$ ./test.ps1

Name                           Value
----                           -----
_                              ./test.ps1
DOTNET_CLI_TELEMETRY_OPTOUT    true
HOME                           /home/bythesea
LANG                           en_GB.UTF-8
LOGNAME                        bythesea
LS_COLORS                      rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:…
MOTD_SHOWN                     pam
OLDPWD                         /home/bythesea
PATH                           /opt/microsoft/powershell/7:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
POWERSHELL_TELEMETRY_OPTOUT    true
POWERSHELL_UPDATECHECK         Off
PSModulePath                   /home/bythesea/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/powershell/7/Modules
PWD                            /home/bythesea/SQLiteConnection-git
SHELL                          /bin/bash
SHLVL                          1
SSH_CLIENT                     172.17.0.1 46240 22
SSH_CONNECTION                 172.17.0.1 46240 172.17.0.4 22
SSH_TTY                        /dev/pts/0
TERM                           xterm-256color
USER                           bythesea
New-SQLiteConnection: /home/bythesea/SQLiteConnection-git/test.ps1:48
Line |
  48 |  … Connection = New-SQLiteConnection -ConnectionString $ConnectionString
     |                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace.
     | If you're using glibc, consider setting the LD_DEBUG environment variable:  /opt/microsoft/powershell/7/SQLite.Interop.dll.so: cannot open shared object file:
     | No such file or directory /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll.so: cannot open shared
     | object file: No such file or directory /opt/microsoft/powershell/7/libSQLite.Interop.dll.so: cannot open shared object file: No such file or directory
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll.so: cannot open shared object file: No such file
     | or directory /opt/microsoft/powershell/7/SQLite.Interop.dll: cannot open shared object file: No such file or directory
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/SQLite.Interop.dll: cannot open shared object file: No such file or
     | directory /opt/microsoft/powershell/7/libSQLite.Interop.dll: cannot open shared object file: No such file or directory
     | /home/bythesea/.local/share/powershell/Modules/rhubarb-geek-nz.SQLiteConnection/1.0.118.0/libSQLite.Interop.dll: cannot open shared object file: No such file or
     | directory

uninstall powershell 7.4.0
$ sudo apt remove powershell

Install 7.3.10
$ curl --fail --location --silent --output powershell_7.3.10-1.deb_amd64.deb https://github.com/PowerShell/PowerShell/releases/download/v7.3.10/powershell_7.3.10-1.deb_amd64.deb
$ sudo dpkg -i ./powershell_7.3.10-1.deb_amd64.deb

Confirm version
$ pwsh
PowerShell 7.3.10
PS /home/bythesea/SQLiteConnection-git> exit

Run from bash again
$ ./test.ps1

Name                           Value
----                           -----
_                              ./test.ps1
DOTNET_CLI_TELEMETRY_OPTOUT    true
HOME                           /home/bythesea
LANG                           en_GB.UTF-8
LOGNAME                        bythesea
LS_COLORS                      rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:…
MOTD_SHOWN                     pam
OLDPWD                         /home/bythesea
PATH                           /opt/microsoft/powershell/7:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
POWERSHELL_TELEMETRY_OPTOUT    true
POWERSHELL_UPDATECHECK         Off
PSModulePath                   /home/bythesea/.local/share/powershell/Modules:/usr/local/share/powershell/Modules:/opt/microsoft/powershell/7/Modules
PWD                            /home/bythesea/SQLiteConnection-git
SHELL                          /bin/bash
SHLVL                          1
SSH_CLIENT                     172.17.0.1 46240 22
SSH_CONNECTION                 172.17.0.1 46240 172.17.0.4 22
SSH_TTY                        /dev/pts/0
TERM                           xterm-256color
USER                           bythesea

CONTENT
-------
Hello World

I don't see any difference in the environment variables and LD_LIBRARY_PATH is never set

It is not the same layout as a NuGet library package.

It really should be. If it's not, then I'd argue PowerShell is doing something wrong.

This is the official powershell documentation which we referenced
dependency-on-native-libraries

@rhubarb-geek-nz Thanks for additional information! I don't see difference in envs too. Perhaps you could debug the broken scenario. You need to look  the method internal static IntPtr NativeDllHandler(Assembly assembly, string libraryName).

Please look #20912

@rhubarb-geek-nz, you mentioned the following in the PR description:

7.3.10 finds and loads these shared libraries.
7.4.0 does not look for them on Linux under the RID directory

Can you please double check if the repro steps work as expected on v7.3.10?
I'm asking because there is no change that we know of in the native library resolver between v7.3.x and v7.4.0, so if it's true that the reported issue doesn't happen on v7.3.10, then the root cause must be in somewhere else instead of the native library resolver.

On 7.3.10
First enter pwsh and run the script, then exit and run script with "pwsh .\test.ps1" from command prompt
C:\>pwsh
PowerShell 7.3.10
PS> .\test.ps1

CONTENT
-------
Hello World

PS> exit

C:\>pwsh .\test.ps1

CONTENT
-------
Hello World

@mklement0 Have you any ideas why shebang scenario doesn't work?

I expect the shebang is identical to "pwsh test.ps1" scenario, as /usr/bin/env effectively runs the given command with the provided arguments.
My guess is there is some process initialisation done when the process considers itself interactive that does not happen when it has been directly given the script or command to run.

@rhubarb-geek-nz I still wonder that you reported libSQLite.Interop.dll.so and SQLite.Interop.dll.dll - why the names have two file extensions?

@rhubarb-geek-nz I still wonder that you reported libSQLite.Interop.dll.so and SQLite.Interop.dll.dll - why the names have two file extensions?

It isn't libSQLite.Interop.dll.so, it is just SQLite.Interop.dll.so
My theory is that "SQLite.Interop.dll" is what is in the DllImport statements compiled into System.Data.SQLite.dll.
Then the PowerShell module loader appends the ".so", ".dll" or ".dylib" depending on the OS.
We found this out in Dependency on Native Libraries adds extra file extensions
Where we used "strace" to track down what PowerShell was actually doing.
Look at the package in the PSGallery. They have those names and directories because that is the only combination I could find that worked in all environments.
rhubarb-geek-nz.SQLiteConnection.nuspec
osx-arm64\SQLite.Interop.dll.dylib
win-arm64\SQLite.Interop.dll.dll
README.md
System.Data.SQLite.dll
osx-x64\SQLite.Interop.dll.dylib
win-x64\SQLite.Interop.dll.dll
linux-arm\SQLite.Interop.dll.so
win-arm\SQLite.Interop.dll.dll
win-x86\SQLite.Interop.dll.dll
rhubarb-geek-nz.SQLiteConnection.psd1
linux-arm64\SQLite.Interop.dll.so
SQLiteConnection.dll
linux-x64\SQLite.Interop.dll.so

https://nuget.info/packages/Stub.System.Data.SQLite.Core.NetStandard/1.0.118.0
SQLLite distributes all native assemblies with dll extention! @SteveL-MSFT  we shouldn't change extension in related PR.

I don't use that NuGet for the native libraries because it does not support ARM or ARM64, it is X64 & X86 only.
I had to compile my own native libraries, but they comply with the same ABI. I don't recompile the common System.Data.SQLite.dll.
SQLite.Interop-win and SQLite.Interop
I then had to add the ".dll", ".so" and ".dylib" to get them working in a PowerShell module.

I think you are stuck with it, if you don't append the .so, .dll and .dylib now you will break existing PSGallery modules that work on 7.3.10.
That said, you could look for the exact requested name first before trying again with the appended native extension.

@rhubarb-geek-nz I know only one package - SQLite - where dll extension is used instead of standard platform extension. I believe it is very edge case (but it's in the law.). So obviously current pwsh behavior is a bug we should fix without a fallback to old behavior. I realize this breaks your module, but you can easily fix it by using two versions of the libraries with old and new names. And I'm surprised you didn't report this problem early, but just used a workaround.

And I'm surprised you didn't report this problem early, but just used a workaround.

We did - https://github.com/PowerShell/PowerShell/issues/19277

And I'm surprised you didn't report this problem early, but just used a workaround.

We did - #19277

Thanks for the reminder. I was sure it was supposed to be fixed in SQLite. I still think so now. Obviously it generates unpredictable behavior in other applications. It's always a bad thing to deviate from de facto standards without justifiable need. (Although the analysis showed that we should fix the pwsh code too.)

Once you make the changes to PowerShell I will change my github project to reflect the encoded naming convention, if you accept the name verbatim from the DllImport then I will change all my dlls to SQLite.Interop.dll.
In the UNIX world it is quite standard to have multiple symbolic links with different names pointing to the same shared library, but I don't think that would work well in a NuGet package

This issue is actually a duplicate of #21319, only that this one surfaced it with native library loading while the other one is GAC assembly loading.
The root cause is that the native lib resolver and GAC assembly resolvers are not yet registered when running Import-Module by pwsh -c. It's an unexpected regression from the PR https://github.com/PowerShell/PowerShell/pull/18356, specifically this line of change in ExternalScriptInfo.
We depend on ClrFacade to be referenced early at startup, but seemingly unrelated change could break that assumption.

This is now fixed in 7.4.2

authors: 237dmitry bording daxian-dbw iSazonov rhubarb-geek-nz


text:
Code redundancy fixes

PR Summary
Using selected Roslynator "Redundancy" fixes.
PR Context
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

rebased to remove RCS1032

source: gharchive/pull-request

repo: PowerShell/PowerShell

license: MIT

license_type: permissive

license_source: github-api


text:
Update README and metadata.json for 7.2.0-preview.1 release

PR Summary
Update README and metadata.json for 7.2.0-preview.1 release.
Changes to be noted:

Add pv-ubuntu20
Remove pv-winarm

PR Context

PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[ ] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[x] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

@adityapatwardhan I made a couple fixes. Can you please review again? Thanks!


text:
Update ADOPTERS.md

PR Summary
I have corrected various grammatical errors in ADOPTERS.md.

PR Context

Improved the readability of the ADOPTERS.md file.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes

[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[x] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:

[ ] Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
(which runs in a different PS Host).

[ ] Issue filed:

[ ] Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.

[ ] Issue filed:

[ ] Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).

[ ] Issue filed:

[ ] Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[ ] Issue filed:

@sdwheeler Please merge this pull request.

@iSazonov Made  the suggested changes.


text:
Remove feature tests

PR Summary
Makes feature tests run without the tag (which now causes issues)

PR Context

@TravisEz13 said this needed to be done
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

User-facing changes

[ ] Not Applicable
OR
[x] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[x] Make sure you've added a new test if existing tests do not effectively test the code changed

@TravisEz13 anything specific you need me to do right now?

@RDIL ... I reviewed the usage of test-dailybuild and corrected the logic.

Thanks

@RDIL: Could you please update the PR title and give more details in the summary and context. Right now it could be interpreted that all Pester tests tagged with Feature will be removed, which is certainly not the case.
This PR rather only targets the [feature] tag in commit messages, which were necessary to include Pester tests marked with Feature.

Sure

@PoshChan 	Please remind me in 1 hour

@TravisEz13, all requests start with the magic word Please.

@PoshChan please remind me in an hour

@PoshChan please remind me in 1 hour

@RDIL, I do not understand: please remind me in an hour

@RDIL, will remind you in 1 hour

@RDIL, this is the reminder you requested 1 hour ago

@TravisEz13 this is the reminder you requested an hour ago

authors: PoshChan RDIL ThreeFive-O TravisEz13


text:
PowerShellGet 2.1.4: Credential Providers | Authentication is STILL BROKEN

I don't know why #133 was closed when this is still so COMPLETELY BROKEN
We cannot work with repositories that require credentials unless we ...
... pass credentials
... with every,
... single
... call.
That's not how any of this is supposed to work.
For example, following the docs for the Azure Artifacts CredProvider, and the blog post from earlier this month we should be able to install the credential provider:
iwr https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -out ~\Downloads\installcredprovider.ps1
~\Downloads\installcredprovider.ps1 -AddNetfx

Set something like this:
$ENV:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS = @'
{
   "endpointCredentials": [{
      "endpoint":"https://poshcode.pkgs.visualstudio.com/_packaging/PowerShell/nuget/v2",
      "username":"Jaykul",
      "password":"thisshouldbeareaallylongpattokenstringyougetfromtheweb"
   }]}
'@

Register the feed:
Register-PSRepository -Name Test -Source https://poshcode.pkgs.visualstudio.com/_packaging/PowerShell/nuget/v2

And get a list of modules:
Find-Module * -Repository Test

But what actually happens is that with no error I get no results.
But if I try it with nuget:
nuget sources add -Name Test -Source https://poshcode.pkgs.visualstudio.com/_packaging/PowerShell/nuget/v2

nuget list -source Test

It works fine, and I get a list of modules...
YOU'RE DOING IT WRONG
The problem is that PowerShellGet isn't looking up the credentials against the feed address.
Instead, it's looking up (or rather, relying on nuget to) the credentials against the final url with all the parameters in it. So we can make the Find-Module command work if we change the stored endpoint to this:
$ENV:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS = @'
{
   "endpointCredentials": [{
      "endpoint":"https://poshcode.pkgs.visualstudio.com/_packaging/PowerShell/nuget/v2/FindPackagesById()?id='*'&$skip={0}&$top={1}",
      "username":"Jaykul",
      "password":"thisshouldbeareaallylongpattokenstringyougetfromtheweb"
   }]}
'@

And then re-run:
Find-Module * -Repository Test

But this is because I've hard-coded the token to a particular search.
Of course the result is that when we don't use the environment variable (i.e. Remove-Item ENV:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS) and do a Find-Module we get a "devicelogin" from the credential provider, but the credentials are cached for that specific URL, so if we Find-Module for any other specific module, or try anything else (like Install-Module), they will fail to find the cached credentials, and require going through the "devicelogin" again...
The worst part is that each time we go through the device login, you're creating a new PAT token that you'll never re-use...
Please, fix it again.

Getting out a PackageMangement release today that will fix this!

I just got version 2.1.5 of PowershellGet but I'm still not truly able to use it with AzureDevops feeds at all as described in here. Here's what I did in my repro:
1). Install Windows 10 1903 from scratch
2). Run elevated powershell session
3). Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
4). Set-PSRepository -Name PSGallery -InstallationPolicy Truste
5). Install-Module -Name Package PowershellGet -Force (to install 2.1.5)
6). close powershell session and start a new one
7). Register-PSRepository -Name PrivatePSGallery -SourceLocation 'https://pkgs.dev.azure.com/myaccount/_packaging/myfeed/nuget/v2' -InstallationPolicy trusted -PackageManagementProvider nuget -Credential $vscred
($vscred is a System.Management.Automation.PSCredential object created using my Azure Devops PAT, myaccount and myfeed are our private Azure Devops account and feed names)
With this version, I get past Register-PSRepository. Previously I'd get an error about SourceLocation being an invalid web uri.
8). Install-Module -Name 'MyModule' -Repository PrivatePSGallery -Credential $vscred
but I receive an error instead.

What am I doing wrong here? Isn't this a supported use case for version 2.1.4 or newer?

Thanks for all the feedback, and patience--we've released updates to both PackageManagement and PowerShellGet yesterday to fix this and I wanted to see if that had resolved the issues you are facing?
CC: @alerickson

still having a lot of trouble using Publish-Script and Publish module from an azure devops pipeline...
here's the relevant snippets from my azure-pipelines.yml
jobs:
  - job: PublishScripts
    pool:
      vmImage: 'vs2017-win2016'
    steps:
    - pwsh: |
        Install-Module -Name PackageManagement -Force -AllowClobber
        Install-Module -Name PowerShellGet -Force -AllowClobber
      displayName: Update PackageManagement

    - pwsh: |
        Import-Module -Name 'PackageManagement' -RequiredVersion '1.4.2'
        Import-Module -Name 'PowerShellGet' -RequiredVersion '2.1.5'

        $galleryName = '****'
        $galleryUrl = 'https://pkgs.dev.azure.com/****/_packaging/****/nuget/v2'

        #get azuredevops credentials
        $password = ConvertTo-SecureString $env:SYSTEM_ACCESSTOKEN -AsPlainText -Force
        $creds = New-Object System.Management.Automation.PSCredential $env:BUILD_REQUESTEDFOREMAIL, $password

        $regparams = @{
          Name = $galleryName
          InstallationPolicy = 'Trusted'
          SourceLocation = $galleryUrl
          PublishLocation = $galleryUrl
          ScriptPublishLocation = $galleryUrl
          Credential = $creds
        }

        Register-PSRepository @regparams -Verbose -Debug
      displayName: Register-PSGallery
      env:
        SYSTEM_ACCESSTOKEN: $(System.AccessToken)

When specifying the credentials using the environment variable, I also get an error.
jobs:
  - job: PublishScripts
    pool:
      vmImage: 'vs2017-win2016'

    steps:
    - pwsh: |
        Install-Module -Name PackageManagement -Force -AllowClobber
        Install-Module -Name PowerShellGet -Force -AllowClobber
      displayName: Update PackageManagement

    - pwsh: |
        Import-Module -Name 'PackageManagement' -RequiredVersion '1.4.2'
        Import-Module -Name 'PowerShellGet' -RequiredVersion '2.1.5'

        $Env:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS = @"
        {"endpointCredentials":[{"endpoint":"https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2","username":"ignored","password":"$($Env:SYSTEM_ACCESSTOKEN)"}]}
        "@

        $galleryName = '***'
        $galleryUrl = 'https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2'

        $regparams = @{
          Name = $galleryName
          InstallationPolicy = 'Trusted'
          SourceLocation = $galleryUrl
          PublishLocation = $galleryUrl
          ScriptPublishLocation = $galleryUrl
        }

        Register-PSRepository @regparams -Verbose -Debug
      displayName: Register-PSGallery
      env:
        SYSTEM_ACCESSTOKEN: $(System.AccessToken)

2019-06-24T19:52:15.8143537Z ##[section]Starting: Register-PSGallery
2019-06-24T19:52:15.8248034Z ==============================================================================
2019-06-24T19:52:15.8248088Z Task         : PowerShell
2019-06-24T19:52:15.8248123Z Description  : Run a PowerShell script on Linux, macOS, or Windows
2019-06-24T19:52:15.8248159Z Version      : 2.151.1
2019-06-24T19:52:15.8248354Z Author       : Microsoft Corporation
2019-06-24T19:52:15.8248390Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
2019-06-24T19:52:15.8248426Z ==============================================================================
2019-06-24T19:52:16.6774021Z Generating script.
2019-06-24T19:52:16.7214837Z ========================== Starting Command Output ===========================
2019-06-24T19:52:16.7469045Z ##[command]"C:\Program Files\PowerShell\6\pwsh.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a\_temp\4741cb7d-7a6f-4067-a038-58b6c3b68f4f.ps1'"
2019-06-24T19:52:27.8573592Z DEBUG: Ping-Endpoint: location=https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2, statuscode=401, resolvedLocation=https://pkgs.dev.azure.com/BrandMuscle/_packaging/BMIPowershellGallery/nuget/v2
2019-06-24T19:52:28.4476205Z DEBUG: 00:00:00.0000001 Calling New() : MethodName = 'GetDynamicOptions'
2019-06-24T19:52:28.4479098Z DEBUG: 00:00:00.0000678 Name: ***
2019-06-24T19:52:28.4484211Z DEBUG: 00:00:00.0000856 Location: https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2
2019-06-24T19:52:28.4489770Z DEBUG: 00:00:00.0001024 Verbose: True
2019-06-24T19:52:28.4490534Z DEBUG: 00:00:00.0001150 Trusted: True
2019-06-24T19:52:28.4490718Z DEBUG: 00:00:00.0001262 Debug: True
2019-06-24T19:52:28.4495673Z DEBUG: 00:00:00.0011488 INVOKING PowerShell Fn Get-DynamicOptions with args Provider that has length 1
2019-06-24T19:52:28.4496932Z DEBUG: 00:00:00.0108756 In PowerShellGet Provider - 'Get-DynamicOptions'.
2019-06-24T19:52:28.4500613Z DEBUG: 00:00:00.0298542 Done calling powershell Â«Get-DynamicOptionsÂ» Â«PSModuleÂ»
2019-06-24T19:52:28.4503769Z DEBUG: 00:00:00.0329736 Calling New() : MethodName = 'GetDynamicOptions'
2019-06-24T19:52:28.4507427Z DEBUG: 00:00:00.0329975 Name: ***
2019-06-24T19:52:28.4508555Z DEBUG: 00:00:00.0330100 Location: https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2
2019-06-24T19:52:28.4561839Z DEBUG: 00:00:00.0330219 Verbose: True
2019-06-24T19:52:28.4561946Z DEBUG: 00:00:00.0330341 Trusted: True
2019-06-24T19:52:28.4562000Z DEBUG: 00:00:00.0330444 Debug: True
2019-06-24T19:52:28.4562079Z DEBUG: 00:00:00.0455502 INVOKING PowerShell Fn Get-DynamicOptions with args Source that has length 1
2019-06-24T19:52:28.4562135Z DEBUG: 00:00:00.0461873 In PowerShellGet Provider - 'Get-DynamicOptions'.
2019-06-24T19:52:28.4562374Z DEBUG: 00:00:00.0612812 Done calling powershell Â«Get-DynamicOptionsÂ» Â«PSModuleÂ»
2019-06-24T19:52:28.4739235Z DEBUG: 00:00:00.0904803 Calling New() : MethodName = 'ResolvePackageSources'
2019-06-24T19:52:28.4747556Z DEBUG: 00:00:00.0911310 Name: ***
2019-06-24T19:52:28.4763422Z DEBUG: 00:00:00.0919322 PackageManagementProvider: NuGet
2019-06-24T19:52:28.4763516Z DEBUG: 00:00:00.0927072 Debug: True
2019-06-24T19:52:28.4776409Z DEBUG: 00:00:00.0933152 ProviderName: PowerShellGet
2019-06-24T19:52:28.4776797Z DEBUG: 00:00:00.0938633 ScriptPublishLocation: https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2
2019-06-24T19:52:28.4913906Z DEBUG: 00:00:00.0944756 PublishLocation: https://pkgs.dev.azure.com/***/_packaging/***/nuget/v2
2019-06-24T19:52:28.5099152Z DEBUG: 00:00:00.0997836 MessageResolver: Microsoft.PowerShell.PackageManagement.Cmdlets.GetMessageString
2019-06-24T19:52:28.5099329Z DEBUG: 00:00:00.1151458 Verbose: True
2019-06-24T19:52:28.5114411Z DEBUG: 00:00:00.1207929 Location: https://pkgs.dev.azure.com/BrandMuscle/_packaging/BMIPowershellGallery/nuget/v2
2019-06-24T19:52:28.5117941Z DEBUG: 00:00:00.1236430 Trusted: True
2019-06-24T19:52:28.5140050Z DEBUG: 00:00:00.1302943 INVOKING PowerShell Fn Resolve-PackageSource with args  that has length 0
2019-06-24T19:52:28.5213906Z DEBUG: 00:00:00.1368437 In PowerShellGet Provider - 'Resolve-PackageSource'.
2019-06-24T19:52:28.5881822Z VERBOSE: Repository details, Name = 'PSGallery', Location = 'https://www.powershellgallery.com/api/v2'; IsTrusted = 'False'; IsRegistered = 'True'.
2019-06-24T19:52:28.5889863Z DEBUG: 00:00:00.2055089 Yielding package source for PSGallery at location https://www.powershellgallery.com/api/v2
2019-06-24T19:52:28.5921091Z DEBUG: 00:00:00.2083705 Done calling powershell Â«Resolve-PackageSourceÂ» Â«PSModuleÂ»
2019-06-24T19:52:28.7081217Z PackageManagement\Register-PackageSource : Unhandled Exception - Message:'One or more errors occurred. (PowerShell is in NonInteractive mode. Read and Prompt functionality is not available.)' Name:'AggregateException' Stack Trace:'   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
2019-06-24T19:52:28.7082498Z    at Microsoft.PowerShell.PackageManagement.Cmdlets.RegisterPackageSource.ProcessRecordAsync()
2019-06-24T19:52:28.7082618Z    at Microsoft.PowerShell.PackageManagement.Cmdlets.AsyncCmdlet.<>c__DisplayClass83_0.<AsyncRun>b__0()'
2019-06-24T19:52:28.7083008Z At C:\Users\VssAdministrator\Documents\PowerShell\Modules\PowerShellGet\2.1.5\PSModule.psm1:11323 char:17
2019-06-24T19:52:28.7083961Z + ...     $null = PackageManagement\Register-PackageSource @PSBoundParamete ...
2019-06-24T19:52:28.7084444Z +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-06-24T19:52:28.7084889Z + CategoryInfo          : InvalidOperation: (Microsoft.PowerShel\u2026gisterPackageSource:RegisterPackageSource) [Register-PackageSource], Exception
2019-06-24T19:52:28.7085373Z + FullyQualifiedErrorId : UnhandledException,Microsoft.PowerShell.PackageManagement.Cmdlets.RegisterPackageSource
2019-06-24T19:52:28.7085716Z
2019-06-24T19:52:28.8216220Z ##[error]PowerShell exited with code '1'.
2019-06-24T19:52:28.8556689Z ##[section]Finishing: Register-PSGallery

As a workaround for this broken experience in azure devops / azure artifacts powershell repository experience you can use a local repo and the builtin nuget commands in VSTS to publish.
You will need to handle the dependencies by publishing them first or specifying as externalDependencies.
I created a gist here of a pipeline that uses this workaround.
https://gist.github.com/jasonchester/12597c0af92e65b728644155a19f05a3

@SydneyhSmith the new release is so much better, but still broken.
EVERY TIME I search for a module that is not in the authenticated feed, I get prompted for credentials.
Simple repro:
Assuming I have installed the Nuget Credential provider using the script from their github in an elevated console:
#requires -RunAsAdministrator
iwr https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -out ~\Downloads\installcredprovider.ps1
~\Downloads\installcredprovider.ps1 -AddNetfx

And I have updated to the current versions of both relevant modules:
Install-Module PackageManagement -RequiredVersion "1.4.2" -SkipPublisherCheck
Install-Module PowerShellGet -RequiredVersion "2.1.5"

In a new window ...
Register-PSRepository -Name PoshCode -SourceLocation https://pkgs.dev.azure.com/poshcode/_packaging/PowerShell/nuget/v2 -InstallationPolicy Trusted

# Find a module that's in that feed, it works! Huzzah!
Find-Module ModuleBuilder

But then ...
# Find a module that's NOT in that feed:
Find-Module PowerShellGet

At this point, it appears that whenever it fails to find a module in the Azure feed that requires credentials, it re-prompts for credentials, and regenerates a new PAT token.
If I again search for a module that does exist in my feed, it works fine. But  the next time I search for one that does not exist in my feed, it prompts for credentials!

Ok, update ...
After re-installing the credential helper (with -Force) I've been able to get this to work now ... I think.
# -Force to install latest credential provider
iwr https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1 -out ~\Downloads\installcredprovider.ps1
~\Downloads\installcredprovider.ps1 -AddNetfx -Force

# Update to latest modules
Find-Module PackageManagement, PowerShellGet -Repository PSGallery |
Install-Module -Name { $_.Name } -RequiredVersion { $_.Version } -Repository PSGallery -SkipPublisherCheck -AllowClobber -verbose

After exiting all PowerShell windows and re-opening, I was able to register and search for modules both in my feed and the PSGallery feed.
Register-PSRepository -Name PoshCode -SourceLocation https://pkgs.dev.azure.com/poshcode/_packaging/PowerShell/nuget/v2

Additionally, putting JSON in ENV:VSS_NUGET_EXTERNAL_FEED_ENDPOINTS seems to work now too.

Ugh. Ok, maybe not. I don't understand. I tested this in PS5 earlier today and it worked.
Just now I ran a Find-Module without thinking in PS6, and it went back to requesting credentials when it couldn't find a module in our repo -- and NOW, PS5 seem broken again too. I don't understand at all.

I'm not sure this should be closed. I'm hitting all the same errors you're hitting.

@nhudacin we just published PowerShellGet and PackageManagement to our int gallery (www.poshtestgallery.com/api/v2) to resolve these error. Please feel free to test these out and see if behavior is working appropriately. The credential provider should only be prompted if the -credential parameter is not passed in.
You can register the int gallery and install the respective modules by running:
Register-PSRepository -Name PoshTestGallery -SourceLocation https://www.poshtestgallery.com/api/v2
Install-Module PowerShellGet, PackageManagement -Repository PoshTestGallery -Force

Thanks @SydneyhSmith. I installed the two modules from your int gallery, closed all of my powershell windows, and opened up a fresh one. I'm getting all sorts of errors now:
~> Register-PSRepository -Name 'internal' -SourceLocation 'https://pkgs.dev.azure.com/my_org/_packaging/powershell/nuget/v2'   -InstallationPolicy Trusted
Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9330 char:5
+     Start-Process $filename -ArgumentList "$arguments -V minimal" `
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9337 char:5
+     Start-Process $filename -ArgumentList "$argumentsNoRetry -V verbo ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Exception calling "Match" with "2" argument(s): "Value cannot be null.
Parameter name: input"
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9346 char:5
+     $username = [System.Text.RegularExpressions.Regex]::Match($conten ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

Exception calling "Match" with "2" argument(s): "Value cannot be null.
Parameter name: input"
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9347 char:5
+     $password = [System.Text.RegularExpressions.Regex]::Match($conten ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9330 char:5
+     Start-Process $filename -ArgumentList "$arguments -V minimal" `
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9337 char:5
+     Start-Process $filename -ArgumentList "$argumentsNoRetry -V verbo ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Exception calling "Match" with "2" argument(s): "Value cannot be null.
Parameter name: input"
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9346 char:5
+     $username = [System.Text.RegularExpressions.Regex]::Match($conten ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

Exception calling "Match" with "2" argument(s): "Value cannot be null.
Parameter name: input"
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2\PSModule.psm1:9347 char:5
+     $password = [System.Text.RegularExpressions.Regex]::Match($conten ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

Register-PSRepository : The specified repository 'internal' is unauthorized and cannot be registered. Try running
with -Credential.
At line:1 char:1
+ Register-PSRepository -Name 'internal' -SourceLocation 'https:// ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : RepositoryCannotBeRegistered,Register-PSRepository

@nhudacin you’ll need the credential provider itself installed (see: https://devblogs.microsoft.com/powershell/using-powershellget-with-azure-artifacts/#).  Those errors aren’t helpful but if you don’t have the credential provider installed you’ll need to use the -credential parameter

I fully agree with Jaykul : it is not really working as it should, is it ?
We are talking about these cmdlets when the the parameter "-Credential" is not used.
Find-Module/Script
Install-Module/Script
Update-Module/Script
Save-Module/Script
Publish-Module/Script

I loose the flow URL token way too often. For example, I should not loose the credential for my private Repository when I browse PSGallery.

The environment variable VSS_NUGET_EXTERNAL_FEED_ENDPOINTS does not seem to be properly used by these cmdlets.

For this reason, until it works properly, I have done the following :

set NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED to "true" (to cache the flow URL token)
set the NUGET_PLUGIN_PATHS to a truncated path (so that the PackageManagement won't try to set the flow URL token itself)
defined my own function that uses the SourceLocation of a PSRepository to get its credential, either
a. via Get-CredsFromCredentialProvider or
b. via the environment variable VSS_NUGET_EXTERNAL_FEED_ENDPOINTS.

Now, I pass this credential returned by my function every time I browse my private PSRepository. If I don't pass the credential, I can get a warning, but I don't loose my token !
Find-Module -Repository myPSRepository -Credential (get-myCredential myPSRepository)
Publish-Module -Name myModule -NuGetApiKey (new-GUID) -Repository myPSRepository -Credential (get-myCredential myPSRepository)

@clientFDJ thanks for reporting this, sorry that you are still hitting these issues...you mentioned that

I loose the flow URL token way too often. For example, I should not loose the credential for my private Repository when I browse PSGallery.

You are correct that this is certainly not intended...in fact calls to the Gallery do not use the credential provider so this is a bit of a strange behavior we are investigating... Are you able to tell if the cache is clearing itself? The credentials should be storing at $env:UserProfile\AppData\Local\MicrosoftCredentialProvider in the file sessiontokencache.dat ...when you experience losing the credential, are you getting re-prompted with the device flow url?
Any specific re-pro steps here would be very helpful...could you also please provide the output of Get-Installed Module PowerShellGet, PackageManagement ? Thanks for all your help!

I'm having the same kind of issues.  I used a PAT to setup my repository.  When I used "Find-Module", I received the following error:
PS> Find-Module simplysql
   at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenNonInteractiveHandler.PreTokenRequestAs
ync()
   at Microsoft.IdentityModel.Clients.ActiveDirectory.Internal.Flows.AcquireTokenHandlerBase.RunAsync()
   at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext.AcquireTokenCommonAsync(String resource, Str
ing clientId, UserCredential userCredential)
   at Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContextIntegratedAuthExtensions.AcquireTokenAsync(Au
thenticationContext ctx, String resource, String clientId, UserCredential userCredential)
   at NuGetCredentialProvider.CredentialProviders.Vsts.AdalTokenProvider.AcquireTokenWithWindowsIntegratedAuth(Cancellat
ionToken cancellationToken) in E:\A\_work\199\s\CredentialProvider.Microsoft\CredentialProviders\Vsts\AdalTokenProvider.
cs:line 120
   at NuGetCredentialProvider.CredentialProviders.Vsts.WindowsIntegratedAuthBearerTokenProvider.GetTokenAsync(Uri uri, C
ancellationToken cancellationToken) in E:\A\_work\199\s\CredentialProvider.Microsoft\CredentialProviders\Vsts\BearerToke
nProviders.cs:line 58
   at NuGetCredentialProvider.CredentialProviders.Vsts.VstsCredentialProvider.HandleRequestAsync(GetAuthenticationCreden
tialsRequest request, CancellationToken cancellationToken) in E:\A\_work\199\s\CredentialProvider.Microsoft\CredentialPr
oviders\Vsts\VstsCredentialProvider.cs:line 88
        ErrorCode: password_required_for_managed_user
[Minimal] [CredentialProvider]DeviceFlow: https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
[Minimal] [CredentialProvider]ATTENTION: User interaction required.

    **********************************************************************
    To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code FTNG3UPNR to authenticate.
    **********************************************************************

Versions of Installed Modules:
Version              Name
-------              ----
1.4.3                PackageManagement
2.2                  PowerShellGet

Here is the relevant VERBOSE output prior to the error above:
VERBOSE: The specified Location is 'https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2' and
PackageManagementProvider is 'NuGet'.
VERBOSE: Retry downloading 'https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2' for '2' more times
VERBOSE: Retry downloading 'https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2' for '1' more times
VERBOSE: Retry downloading 'https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2' for '0' more times
VERBOSE: [Verbose] [CredentialProvider]Running in stand-alone mode
VERBOSE: [Verbose] [CredentialProvider]Command-line v0.1.17:
C:\Users\rmartin\.nuget\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll -V verbose -U
https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]Handling auth request, Uri:
https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2, IsRetry: False, IsNonInteractive: False, CanShowDialog:
False
VERBOSE: [Verbose] [CredentialProvider]URI: https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]VstsBuildTaskServiceEndpointCredentialProvider - This credential provider must
be run under the Team Build tasks for NuGet with external endpoint credentials. Appropriate environment variable needs
to be set.
VERBOSE: [Verbose] [CredentialProvider]Skipping
NuGetCredentialProvider.CredentialProviders.VstsBuildTaskServiceEndpoint.VstsBuildTaskServiceEndpointCredentialProvider
, cannot provide credentials for https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]VstsBuildTaskCredentialProvider - This credential provider must be run under the
 Team Build tasks for NuGet. Appropriate environment variables must be set.
VERBOSE: [Verbose] [CredentialProvider]Skipping
NuGetCredentialProvider.CredentialProviders.VstsBuildTask.VstsBuildTaskCredentialProvider, cannot provide credentials
for https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]GET https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]IsRetry: False
VERBOSE: [Verbose] [CredentialProvider]Could not find cached SessionToken for
https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]GET https://pkgs.dev.azure.com/ga811/_packaging/geocall/nuget/v2
VERBOSE: [Verbose] [CredentialProvider]Found AAD Authority from 401 headers:
https://login.windows.net/810763ba-110f-4839-801f-546e30e9adc0
VERBOSE: [Verbose] [CredentialProvider]VstsCredentialProvider - Using AAD authority:
https://login.windows.net/810763ba-110f-4839-801f-546e30e9adc0
VERBOSE: [Verbose] [CredentialProvider]VstsCredentialProvider - Attempting to acquire bearer token using provider 'ADAL
 Cache'
VERBOSE: [Verbose] [CredentialProvider]VstsCredentialProvider - Bearer token provider 'ADAL Cache' didn't acquire a
token
VERBOSE: [Verbose] [CredentialProvider]VstsCredentialProvider - Attempting to acquire bearer token using provider 'ADAL
 Windows Integrated Authentication'

So, even though I successfully registered the Repository with a credential (register-psrepository -credential), its not using that credential to when using other PSGet commands. -- This is anything but simply and intuitive.  If a user provides credentials to the command "Register-PSRepository" then that credential should be saved and used whenever a future command is executed against the repository.

I'm not able to get anything to work without -Credential being passed. I tried Jaykul's install method with setting VSS_NUGET_EXTERNAL_FEED_ENDPOINTS.
Register-PSRepository -Name "Test" -SourceLocation "https://pkgs.dev.azure.com/<Organization>/_packaging/<Feed>/nuget/v2" -InstallationPolicy Trusted

returns
Register-PSRepository : The specified repository 'Test' is unauthorized and cannot be registered. Try running with -Credential.
At line:1 char:1
+ Register-PSRepository -Name "Test" -SourceLocation "https://pkgs.dev. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : RepositoryCannotBeRegistered,Register-PSRepository

If I pass -Credential, it registers the repo. Once registered with -Credential, I try
Find-Module -Repository Test

which returns
WARNING: Unable to resolve package source 'https://pkgs.dev.azure.com/<Organization>/_packaging/<Feed>/nuget/v2'.

If I pass -Credential, it returns my modules. Since I can use a credential object, I know my PAT is good. What am I doing wrong?
Module versions:
Version Name
------- ----
2.2     PowerShellGet
1.4.3   PackageManagement

@tcpaddock sorry to hear that you are hitting issues, thanks for commenting on this issue. Could you try running Find-Module * -Repository Test  i.e. the same as above but using the wildcard character, and see what it returns?

@SydneyhSmith with Find-Module * -Repository Test I get
WARNING: Cannot access 'https://pkgs.dev.azure.com/<Organization>/_packaging/<Feed>/nuget/v2'. Are you missing 'Credential' parameter in the cmdlet?
WARNING: Unable to resolve package source 'https://pkgs.dev.azure.com/<Organization>/_packaging/<Feed>/nuget/v2'.

I logged in to Azure DevOps through IE and cached credentials. I'm no longer receiving access denied. Find-Module now returns
WARNING: Query Url https://pkgs.dev.azure.com/<Organization>/_packaging/<Feed>/nuget/v2 is invalid.

There are some private functions like Resolve-Location and Ping-Endpoint that only look at the credential object being passed through. At some level, it looks like a credential object needs to be built from the VSS_NUGET_EXTERNAL_FEED_ENDPOINTS environment variable to be passed to these support functions.

Yeah. This is broken again in 2.2 and 1.4.3
I have PackageManagement v1.4.2 and PowerShellGet v2.1.5 and I'm able to register a feed, get that giant wall of nasty error looking stuff that ends with a "devicelogin" URL and token ... do the login, and then it works.
When I install and load the new versions (PowerShellGet v2.2 and PackageManagement v1.4.3) querying still works against the previously registered feed, but if I try to Register-PSRepository a new Azure DevOps feed, I'm getting the same bogus error that tcpaddock mentioned
Obviously I can't successfully pass credentials, they require MFA or a token...

Is there any update of this?  When using version 2.2.1 and 1.4.4 and the device authentication method the modules can't be found or installed.
When using 2.1.5 and 1.4.2 it is possible to find modules however I am unable to download modules

Any news on that topic? It still seems buggy to me, I'm using Powershell core on Linux.
At some point it showed the device login but not anymore.
Furthermore when trying to find a module I constantly get:
WARNING: Cannot access 'https://pkgs.dev.azure.com/***/PartnerInfra/_packaging/InternalPowershellGallery/nuget/v2'. Are you missing 'Credential' parameter in the cmdlet?
WARNING: Unable to resolve package source 'https://pkgs.dev.azure.com/***/PartnerInfra/_packaging/InternalPowershellGallery/nuget/v2'```

Any clue?

@molinch thanks for commenting on this, would it be possible for you to give us the output of running
Find-Module with the debug parameter? Thanks!

Until this issue is properly addressed by PowerShellGet, I've created the AzureArtifactsPowerShellModuleHelper PowerShell module, which is available on the PowerShell Gallery here. Basically as long as you have the VSS_NUGET_EXTERNAL_FEED_ENDPOINTS environment variable on the local machine, you can use this module to find, install, and update PowerShell modules from you Azure Artifacts without worrying about providing credentials; they'll be automatically injected into all of the calls for you.
It also includes a convenient Install-AndUpdateAzureArtifactsModule helper cmdlet to help address issue #234 until it's fixed properly natively in PowerShellGet.

@deadlydog that's great!  That's in the vein of what, I was thinking should be done to address this issue in v3.  Only read from the VSS_NUGET_EXTERNAL_FEED_ENDPOINTS env var and incorporate cmdlets to allow for installation and configuration.  Would you be interested incorporating any of that work into v3?

@alerickson Yeah I'd be open to working it into v3. Is there a specific branch I should be looking at incorporating it into? Any other info I should know? Thanks.

@deadlydog we'll have a fork with v3 up in the next few weeks.  I can reach out to you as soon as that's up.  There isn't anything else in particular you should know right now.

I tried most of the solutions mentioned in this thread to complete the workflow described in the blog post. I was finally able to install an existing module using the helper @deadlydog created. I haven't been able to find a way to publish a module, even when passing -Credentials.
Publish-PSArtifactUtility : Failed to publish module 'MyModule': 'dotnet cli failed to nuget push info : Pushing
MyModule.nupkg to 'https://pkgs.dev.azure.com/myorg/_packaging/myfeed/nuget/v2'...
info :   PUT https://pkgs.dev.azure.com/myorg/_packaging/myfeed/nuget/v2/
warn : The plugin credential provider could not acquire credentials. Authentication may require manual action.
Consider re-running the command with --interactive for `dotnet`, /p:NuGetInteractive="true" for MSBuild or removing
the -NonInteractive switch for `NuGet`

Any tips?

@jonathaneckman what version of dotnet, PowerShell, and PowerShellGet are you using?

@alerickson

.NET Core 3.1
PowerShellGet 2.2.3
PackageManagement 1.4.6
PowerShell 5.1

@jonathaneckman thanks!  A couple of folks have been running into publishing issues lately, could you let me know if the suggestion proposed here works for you?

Oh, what a thread. Noticed one of my issues referenced here.
After battling https://github.com/PowerShell/PowerShellGet/issues/584 for several days to get a custom module published locally and then exploring Azure artifacts as a distribution channel custom modules, here are some learning:

module publishing is broken for PS Core and dotnet core 2.1+ (issues #584)
fails on both windows/linux, ouch
it is non-trivial to figure out: nuget gets stuck, it is not obvious what is going on
dotnet 2.0.2 seems to bring old nuget so that dotnet nuget pack does the work
PowerShellGet isn't getting build in docker container neither seems to get tested with different dotnet/nuget versions or win/linux platforms for critical paths
a bit challenging to get sources and try to troubleshoot locally

Regarding Azure artifacts as a distribution channel:

Official doco is confusing, PAT-centric and refers to medium blog post

https://docs.microsoft.com/en-us/azure/devops/artifacts/tutorials/private-powershell-library?view=azure-devops

local dev/auth experience via az login is missed
how to get this working under CI/CD is also not clear
auth is broken, constant re-auth, now I know why - because of this ticket :)

Overall, I gave up and packed a custom module as a docker container to make sure that:

it works
environment is pinned (dotnet, nuget, powershell, other modules)
it is friendly to use for local dev and CI/CD environments plus diff OS - win/mac/linux
distribution is still friendly and secure, eg private docker registry

Well, the only challenge is limited workloads which come via mapped folders to do the work and ability to actually install the module on the target system. But can only be done with downgrading dotnet at the moment with PS Core.

The easiest and most consistent way I have found to publish modules to Azure Artifacts is packing and pushing the module with the FSharp package manager paket - since it is a replacement for nuget it bypasses the problems with inconsistent versions and requirements, and it is a single lightweight executable.
I wrote a build task for Invoke-Build that generates a paket.template file from the module manifest, and use that to create the .nupkg file.
Some things to note:

If you use the paket.dependencies file to pull modules from a private repo it will error out if they were not packed with paket or nuget. Evidently Publish-Module does not encode the version the way it's expecting.
I don't actually know if I'm using the token or the cred options, I was playing around with both and I'm scared to break it!
paket lets you test credentials/configs pretty easily with  paket config add-credentials <source URL> --verify

The full workflow I'm using is:

Configure and verify the connection to AzureArtifacts with paket config
paket init  - technically this only needs to be done once.
paket install - technically this only needs to be done once.
build the module
New-PaketTemplate or update the old paket.template file with the new version number
paket pack
paket push

source: gharchive/issue

authors: Jaykul SydneyhSmith alerickson avishnyakov clientFDJ deadlydog jasonchester jonathaneckman ld0614 mithrandyr molinch nhudacin randomchance tcpaddock tristanbarcelon

repo: PowerShell/PowerShellGet


text:
SPAlternateUrl not working with Central Admin

Details of the scenario you try and problem that is occurring:
Use SPAlternateUrl to set HTTPS url for Central Admin's Intranet zone.
Looks like the Get-SPWebApplication just needs to -IncludeCentralAdministration
The DSC configuration that is using the resource:
Version of the Operating System and PowerShell the DSC Target Node is running:
WS2016, WMF 5.1
Version of the DSC module you're using:
2.0

Just submitted a PR which implements the possibility to change the Central Admin URL's. We need to extend this a little more, but wanted to release the PR for the v2.1 release.
Also:
When not using the Set-SPCentralAdministration cmdlet, the link to the CA site in the registry is not updated. This can be solved by using the Registry resource, but that needs to be done for all servers in the farm which is not desirable. Set-SPCentralAdministration will do this automatically on all servers.

Regarding the link to the CA site in the registry, I tested and Set-SPAlternateUrl also updates the registry. It seems to have the same effect as Set-SPCentralAdministration, except it doesn't touch IIS. It executes much faster than Set-SPCentralAdministration, so I'm guessing it's the IIS part that makes Set-SPCentralAdministration take so long.
In my fork that has the CA-specific handling, when SPAlternateUrl runs on only my Central Admin server, it executes Set-SPAlternateUrl, which sets the AAM for CA properly AND updates the CentralAdministrationUrl value on all servers. I didn't realize Set-SPAlternateUrl could do this, but I just tested it again manually and it does indeed work this way. At least, it does in SP2016. It would be worthwhile to test in SP2013 to make sure, but I still think my changes could be a workable solution for CA. Let me know what you think.

Additional improvements are implemented in PR #767

Final fixed merged into dev via PR #767

authors: ronx ykuijs

repo: PowerShell/SharePointDsc


text:
v3.5 release preparations

Pull Request (PR) description
Preparations for the release of v3.5
This Pull Request (PR) fixes the following issues
N/A
Task list

[x] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[x] Resource documentation added/updated in README.md in the resource folder.
[x] Resource parameter descriptions added/updated in schema.mof
and comment-based help.
[x] Comment-based help added/updated.
[x] Localization strings added/updated in all localization files as appropriate.
[x] Examples appropriately added/updated.
[x] Unit tests added/updated. See DSC Resource Testing Guidelines.
[x] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[x] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #1083 into dev will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev   #1083   +/-   ##
=====================================
  Coverage     92%     92%
=====================================
  Files        119     119
  Lines      13141   13141
=====================================
  Hits       12191   12191
  Misses       950     950

authors: codecov-io ykuijs


text:
New-ExternalHelpCab updates the Module.md file

The question is why does it update the version in this MD file?
Steps to reproduce
This is the command the updates the module.md file in our build pipeline:
New-ExternalHelpCab -CabFilesFolder $ModuleOutDir\$locale -LandingPagePath $DocsRootDir\$locale\$ModuleName.md `
                    -OutputFolder $UpdatableHelpOutDir -Verbose:$VerbosePreference > $null

Expected behavior
The documentation for the command mentions nothing about updating the module.md file.  I was expecting this command to not change any of the MD files.  We run this as a part of a build pipeline, having that change "source" files is not good.
Actual behavior
The Plaster.md is updated:

BTW the module version number is 0.3.0 in the Plaster.psd1 file.
Environment data
v0.7.2

@rkeithhill That's by design. When CABs are generated this up versioning is important so that updateable help can pick up the latest.

So you wouldn't recommend this step be part of the normal build pipeline?  Perhaps run manually when someone wants to update the updatable help?

I think we should make it optional. Probably with -SkipVersionUpdate flag or something alike.

I believe the code for increment version is not correct as it only increments the last digit of the version. Another problem that happens with this process is that the new generated module.md file is not checked back into the repo. This means, if the module.md have a version 6.0.0.0 then whenever we run platyps it is always going to generate 6.0.0.1. This is incorrect.
I recommend removing the auto increment from platyps and manually increment the version in the metadata table at top in module.md when the content is changed.
Thoughts? @sankethka @vors @rkeithhill

I have a PR to remove the auto increment of the help version from module.md. #269

@rkeithhill Are we able to close this issue? The PR was merged, and released in 0.8.0.

authors: BernieWhite adityapatwardhan rkeithhill sankethka vors

repo: PowerShell/platyPS

license: mit

license_source: bigquery


text:
xRemoteDesktopSessionCollectionConfiguration: Add configuration for User Profile Disks on W2016+ (Fixes #34)

This version adds the ability to configure User Profile Disks on Windows Server 2016 using the xRemoteDesktopSessionCollectionConfiguration resource. This is built in a way that the new properties are ignored when running on Windows Server 2012 R2.

Added UserProfileDisk specific parameters to resource
Added code to detect running on W2012 (R2) or W2016+
Updated the formatting of some files a bit, to make the code more readable
Added unit tests (I'm ok adding more tests for Set also if we feel we can go ahead merging this PR)

First of all, I would like to get some feedback on the implementation. If we agree this is the right direction I will finish by updating the readme etc.

This change is

@danielboth Can you help resolve the encoding of the schema.mof file, should be UTF-8 (without BOM)? https://ci.appveyor.com/project/PowerShell/xremotedesktopsessionhost/build/1.3.91.0#L28

Codecov Report

Merging #35 into dev will increase coverage by 30.76%.
The diff coverage is 60.36%.

@@             Coverage Diff             @@
##              dev      #35       +/-   ##
===========================================
+ Coverage   15.96%   46.73%   +30.76%
===========================================
  Files           5        5
  Lines         119      199       +80
  Branches        4        4
===========================================
+ Hits           19       93       +74
- Misses         96      102        +6
  Partials        4        4

Impacted Files
Coverage Δ

...ration/MSFT_xRDSessionCollectionConfiguration.psm1
62.9% <60.36%> (+53.81%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1d7210c...a542bc4. Read the comment docs.

@johlju I've updated the schema.mof and added tests for my changes to Set-TargetResource (and a bit more). At least a green build now :)

@ld0614 can you take this review?
@danielboth Awesome work on the tests!

It looks good, thanks for the PR.  There are a number of PSSA rules which need rectifying https://ci.appveyor.com/project/PowerShell/xremotedesktopsessionhost#L218 and the readme and change log will need updating as well.

Review status: 0 of 3 files reviewed at latest revision, all discussions resolved.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 99 at r2 (raw file):

        # This part of the configuration only applies to Win 2016+
        if(([version](Get-CimInstance -ClassName win32_operatingsystem -Property Version).Version).Major -ge 10) {

Should probably use the helper function Get-OsVersion to maintain consistancy

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 198 at r2 (raw file):

    if(([version](Get-CimInstance -ClassName win32_operatingsystem -Property Version).Version).Major -ge 10) {

As above

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 221 at r2 (raw file):

            if(-not($MaxUserProfileDiskSizeGB -gt 0)) {
                Throw "To enable UserProfileDisk we need a setting for MaxUserProfileDiskSizeGB that is greater than 0. Current value $MaxUserProfileDiskSizeGB is not valid"

I would rearrange this if statement so that it matches the one above with the else throwing, -le 0 is also clearer than -not (-gt 0)

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):

2>&1

This should be rewritten as -ErrorAction Continue if that is the desired behaviour or possibly -ErrorAction SilentlyContinue with -ErrorVariable

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 336 at r2 (raw file):

    $isInDesiredState = $true

    if(([version](Get-CimInstance -ClassName win32_operatingsystem -Property Version).Version).Major -lt 10) {

As Above

Comments from Reviewable

Thanks for the feedback @ld0614, I'll get the code fixed, probably won't happen tonight but will get this done in the next two days.

Review status: 0 of 3 files reviewed at latest revision, 5 unresolved discussions.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…

2>&1

This should be rewritten as -ErrorAction Continue if that is the desired behaviour or possibly -ErrorAction SilentlyContinue with -ErrorVariable

I started with this and it seems a bit more challenging than I was thinking before. This due to a bug that I hit when setting up the UserProfileDisk. As you can see in the error message, the error is about two command that cannot be found. I traced this down to the Test-UserVhdPathInUse function that is being called in the module C:\Windows\system32\WindowsPowerShell\v1.0\Modules\RemoteDesktop\Utility.psm1. For some reason that function is not aware of the prefix of the RemoteDesktop commands when running the DSC context. I manually edited the file (after changing the permissions to write for administrators) to include the commands without the -RD prefix, after which the DSC configuration can be applied without any errors.
A second bug I'm hitting is that if you are only changing the size of the UserProfileDisk, for example from 5GB to 6GB, that it will run the command file, but it will not apply the setting. This is also true outside the DSC context. So when a UserProfileDisk is already configured, the size for the disk is not changed when this command is ran:
 Set-RDSessionCollectionConfiguration -CollectionName TestCollection -MaxUserProfileDiskSizeGB 6 -EnableUserProfileDisk -DiskPath c:\temp

The last part I could fix in the resource by disabling the UserProfileDisk configuration first and then enabling it again. But it will keep erroring out on the two functions it cannot find. Any recommendations on how to handle that best?

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 99 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
Should probably use the helper function Get-OsVersion to maintain consistancy

Done, changed Get-OsVersion to Get-xRemoteDesktopSessionHostOsVersion and used that one instead.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 198 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
As above

Done, as above

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 221 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
I would rearrange this if statement so that it matches the one above with the else throwing, -le 0 is also clearer than -not (-gt 0)

Done, switched to -le

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 336 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
As Above

Done, as above

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 221 at r2 (raw file):
Previously, danielboth (Daniël) wrote…
Done.

Apologies if my above comment was unclear, now that you've switched the throw to the else statement the logic of -not(-le) == -gt. -gt is easier to read as its a single comparison rather than needing 2 comparisons.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):
Previously, danielboth (Daniël) wrote…
I started with this and it seems a bit more challenging than I was thinking before. This due to a bug that I hit when setting up the UserProfileDisk. As you can see in the error message, the error is about two command that cannot be found. I traced this down to the Test-UserVhdPathInUse function that is being called in the module C:\Windows\system32\WindowsPowerShell\v1.0\Modules\RemoteDesktop\Utility.psm1. For some reason that function is not aware of the prefix of the RemoteDesktop commands when running the DSC context. I manually edited the file (after changing the permissions to write for administrators) to include the commands without the -RD prefix, after which the DSC configuration can be applied without any errors.
A second bug I'm hitting is that if you are only changing the size of the UserProfileDisk, for example from 5GB to 6GB, that it will run the command file, but it will not apply the setting. This is also true outside the DSC context. So when a UserProfileDisk is already configured, the size for the disk is not changed when this command is ran:
 Set-RDSessionCollectionConfiguration -CollectionName TestCollection -MaxUserProfileDiskSizeGB 6 -EnableUserProfileDisk -DiskPath c:\temp

The last part I could fix in the resource by disabling the UserProfileDisk configuration first and then enabling it again. But it will keep erroring out on the two functions it cannot find. Any recommendations on how to handle that best?

I hit similar issues with loading in the module when working on the HA build currently available https://github.com/ld0614/xRemoteDesktopSessionHost which I'll be pushing once I have written tests for it.  It appears to be a bug in the module implementation I resolved it by taking the approach that the Azure RDS quickstart modifications did (https://github.com/Azure/azure-quickstart-templates/blob/master/rds-deployment/Configuration.zip).  If you look here you can see what I was talking about by using ErrorAction to allow program continuation and then view the output of the error using the ErrorVariable option.

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 221 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
Apologies if my above comment was unclear, now that you've switched the throw to the else statement the logic of -not(-le) == -gt. -gt is easier to read as its a single comparison rather than needing 2 comparisons.

Done. Sorry, obviously one is easier to read. Fixed now :).

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
I hit similar issues with loading in the module when working on the HA build currently available https://github.com/ld0614/xRemoteDesktopSessionHost which I'll be pushing once I have written tests for it.  It appears to be a bug in the module implementation I resolved it by taking the approach that the Azure RDS quickstart modifications did (https://github.com/Azure/azure-quickstart-templates/blob/master/rds-deployment/Configuration.zip).  If you look here you can see what I was talking about by using ErrorAction to allow program continuation and then view the output of the error using the ErrorVariable option.

Ok, I like the way the CommandNotFoundException is checked, so I modified the code to align with what the workaround you showed is doing. However, it does not work with just -ErrorAction SilentlyContinue and -ErrorVariable. Even with both of those, the CommandNotFoundException still shows up in the error stream so I see no other solution than to redirect the error stream. I captured what I did in a small video (see here: https://1drv.ms/v/s!AorMCX2HQHeyg_h-0aB_Aso4e1SMDQ). Here I start with redirecting the error stream, after which everything is handeled nicely, also visible in the verbose stream. If I take the redirection of the error stream of, by commenting it out, the errors show up in the next run right away.
Do you see any reason not to workaround the problem by redirecting the error stream? I would like to learn about the reasoning behind this.

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):
Previously, danielboth (Daniël) wrote…
Ok, I like the way the CommandNotFoundException is checked, so I modified the code to align with what the workaround you showed is doing. However, it does not work with just -ErrorAction SilentlyContinue and -ErrorVariable. Even with both of those, the CommandNotFoundException still shows up in the error stream so I see no other solution than to redirect the error stream. I captured what I did in a small video (see here: https://1drv.ms/v/s!AorMCX2HQHeyg_h-0aB_Aso4e1SMDQ). Here I start with redirecting the error stream, after which everything is handeled nicely, also visible in the verbose stream. If I take the redirection of the error stream of, by commenting it out, the errors show up in the next run right away.
Do you see any reason not to workaround the problem by redirecting the error stream? I would like to learn about the reasoning behind this.

hmm, thanks for the video, I'll see if I can recreate the issue on my side, the reason for me disliking using a stream redirect is that its not especially clear whats going on (kind of like using % or instead of foreach).
What about something like this? I've not tested it yet but in theory I belive that it should handle only command not found exceptions while throwing all others from the orgion.  I also think its easier to read while actually following PowerShell pylosofy a bit better, @johlju what are your thoughts?
try
{
    $null = Set-RDSessionCollectionConfiguration @enableUserProfileDiskSplat -ErrorAction Stop
}
catch [System.Management.Automation.CommandNotFoundException]
{
    Write-Verbose "Set-RDSessionCollectionConfiguration: trapped erroneous CommandNotFoundException errors, that's ok, continuing..."
}

Comments from Reviewable

From a PowerShell perspective you are completely right @ld0614. In this case however, that doesn't work, since Set-RDSessionCollectionConfiguration with -ErrorAction Stop will actually stop executing the required code when you try - catch like this. It does not continue anymore. This means all the code after the first CommandNotFoundException is not executed, which would break the actual changing of the session collection configuration (I tested this to confirm and indeed, it does not change the config anymore).
I think this is the reason the Azure configuration also uses the workaround this way. Not beautiful for sure, but we would need a bugfix from Microsoft on the RemoteDesktop module before we can do this properly.

Review status: all files reviewed at latest revision, 1 unresolved discussion.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
hmm, thanks for the video, I'll see if I can recreate the issue on my side, the reason for me disliking using a stream redirect is that its not especially clear whats going on (kind of like using % or instead of foreach).
What about something like this? I've not tested it yet but in theory I belive that it should handle only command not found exceptions while throwing all others from the orgion.  I also think its easier to read while actually following PowerShell pylosofy a bit better, @johlju what are your thoughts?
try
{
    $null = Set-RDSessionCollectionConfiguration @enableUserProfileDiskSplat -ErrorAction Stop
}
catch [System.Management.Automation.CommandNotFoundException]
{
    Write-Verbose "Set-RDSessionCollectionConfiguration: trapped erroneous CommandNotFoundException errors, that's ok, continuing..."
}

😟 I guess we'll have to run with it then, would I be able to ask that you just comment either on the line or above it something like '2>&1 redirects the error stream to output strream' please?

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion.

DSCResources/MSFT_xRDSessionCollectionConfiguration/MSFT_xRDSessionCollectionConfiguration.psm1, line 238 at r2 (raw file):
Previously, ld0614 (Leo D'Arcy) wrote…
😟 I guess we'll have to run with it then, would I be able to ask that you just comment either on the line or above it something like '2>&1 redirects the error stream to output strream' please?

Comment added on the line above the redirection.

Comments from Reviewable

Thanks, if no one has any objections I'll merge tomorrow afternoon

Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

authors: codecov-io danielboth johlju ld0614

repo: PowerShell/xRemoteDesktopSessionHost


text:
xSQLServerAlwaysOnService: Fix PSSA rules

Pull Request (PR) description
As raised in #724 there are PSSA errors caused by $null comparison being the wrong way round.
This Pull Request (PR) fixes the following issues:
Fixes #724
Task list:

[x] Change details added to Unreleased section of CHANGELOG.md?
[ ] Added/updated documentation, comment-based help and descriptions in .schema.mof files where appropriate?
[ ] Examples appropriately updated?
[ ] New/changed code adheres to Style Guidelines?
[ ] Unit and (optional) Integration tests created/updated where possible?

This change is

@ChrisLGardner,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Codecov Report

Merging #765 into dev will not change coverage.
The diff coverage is 100%.

@@         Coverage Diff         @@
##            dev   #765   +/-   ##
===================================
  Coverage    97%    97%
===================================
  Files        30     30
  Lines      3250   3250
===================================
  Hits       3165   3165
  Misses       85     85

@ChrisLGardner Please add this change to the CHANGELOG.md.

Done.

Reviewed 1 of 1 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

CHANGELOG.md, line 54 at r2 (raw file):

Analyser

Change to 'Analyzer' here asx well. Please change the other PR's as well. :smile:

DSCResources/MSFT_xSQLServerAlwaysOnService/MSFT_xSQLServerAlwaysOnService.psm1, line 211 at r2 (raw file):

    # Determine the current state of Always On
    $getTargetResourceParameters = @{
        Ensure          = $Ensure

Ensure          = $Ensure
SQLServer       = $SQLServer
SQLInstanceName = $SQLInstanceName

Please keep the indentation here, because VS Code auto-format align these this way ( using Alt-Shift-F).

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions.

CHANGELOG.md, line 54 at r2 (raw file):
Previously, johlju (Johan Ljunggren) wrote…

Analyser

Change to 'Analyzer' here asx well. Please change the other PR's as well. :smile:

Done.

DSCResources/MSFT_xSQLServerAlwaysOnService/MSFT_xSQLServerAlwaysOnService.psm1, line 211 at r2 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
Ensure          = $Ensure
SQLServer       = $SQLServer
SQLInstanceName = $SQLInstanceName

Please keep the indentation here, because VS Code auto-format align these this way ( using Alt-Shift-F).

Done.

Comments from Reviewable

@ChrisLGardner Please rebase this PR. Please use git rebase (not git merge or git pull).
Help is here; https://github.com/PowerShell/DscResources/blob/master/GettingStartedWithGitHub.md#resolve-merge-conflicts

Rebased as requested. I might need to rebase one of these again once it's merged.

Reviewed 1 of 2 files at r4, 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

CHANGELOG.md, line 54 at r2 (raw file):
Previously, ChrisLGardner wrote…
Done.

You missed this one, it still 'Analyser' :)

Comments from Reviewable

Rebased now.

Review status: 1 of 2 files reviewed at latest revision, 1 unresolved discussion.

CHANGELOG.md, line 54 at r2 (raw file):
Previously, johlju (Johan Ljunggren) wrote…
You missed this one, it still 'Analyser' :)

Done.

Comments from Reviewable

Reviewed 1 of 1 files at r6.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

authors: ChrisLGardner codecov-io johlju msftclas

repo: PowerShell/xSQLServer


text:
Improved BindingInfo validation for xWebsite

Improved BindingInfo validation for xWebsite: the HostName property is now required for use with Server Name Indication (i.e., when the SslFlags property is set to 1 or 3).
The Test-TargetResource should return the following error if the HostName binding property is either empty or is not specified:

Trimmed trailing spaces.

Can I suggest connecting your GitHub account up to Reviewable.io for this repo? It makes reviewing way easier.

LGTM - thanks for all the work on this @SNikalaichyk

Hello! There are also some pending changes by @nzspambot in #132 . Can we postpone restyling of this module to avoid merge conflicts until the next time?

@SNikalaichyk - Ok cool. Sounds like a good idea.

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

So this looks good to me, am I merging #135 or does it really matter?

So I should probably do this one first then and let you (@nzspambot) deal with the smaller merge then? :grin:

authors: PlagueHO SNikalaichyk tysonjhayes

repo: PowerShell/xWebAdministration


text:
🛑 HDArea is down

In 27ce5b9, HDArea ($HDAREA) was down:

HTTP code: 502
Response time: 856 ms

Resolved: HDArea is back up in 2faaabb after 6 minutes.

repo: PowerfulRichard/PT-Status


text:
Скорректирована запись ошибки в отчет jUnit

Реализация  #412
сделанные изменения

запись текста ошибки переделана с записи атрибута на запись значения

Спасибо!

authors: Pr-Mex theshadowco

repo: Pr-Mex/vanessa-automation