[BUG] PnP and Azure functions assembly conflict. Could not load type 'Microsoft.Extensions.Logging.Abstractions.Internal.NullScope' from assembly 'Microsoft.Extensions.Logging.Abstractions'

[jmartncp]

Reporting an Issue or Missing Feature

This is an issue related to PnP using a conflicting assembly dependency than what
the Azure functions service loads by default. To be more specific, the issue occurs for us
with the module Microsoft.Extensions.Logging.Abstractions on each call of
Connect-PnPOnline. PowerShell 7.2 on Azure functions automatically loads
version 3.0.3.0 while the one included with PnP is 2.2.0.0. I have tried many
potential resolutions but have been unable to fix (Wrapping in ThreadJob does not work).
The one solution about downgrading from 7.2 to 7.0 is not an option for us, as we require
7.2 for its functionalities. Due to this issue, we are unable to rely on PnP for our needs at
the moment. If a fix for PnP in this scenario is possible, please do. If not, then notify of any
possible workarounds. This problem had me stumped for a while, so anything that can be
done about it is appreciated.

Expected behavior

Successful connection via Connect-PnPOnline cmdlet.

Actual behavior

An error related to a module in Azure functions:

Steps to reproduce behavior

• Create an Azure functions app version 4.0 and set it to use PowerShell 7.2
• Add PnP.PowerShell 1.10.0 to the requirements.psd1 file.
• Create a basic function that just tries to execute Connect-PnPOnline. Ensure it logs error info.
• Deploy the function to the cloud and execute via your API. (<app_url>/api/<func_name>)
• Wait a bit for logs to save, then go to monitor log menu for that function.
• View its logs and observe error.

NOTE: To reproduce, ensure code is run in the cloud within an Azure function. Running Connect-PnPOnline
locally will likely NOT cause an error. (The Azure assemblies won't be loaded)

What is the version of the Cmdlet module you are running?

PnP.PowerShell 1.10.0, PowerShell Core 7.2

Which operating system/environment are you running PnP PowerShell on?

• Linux
• MacOS
• Windows
• Azure Cloud Shell
• Azure Functions
• Other : please specify

[CallumCrowley]

@jmartncp bit of a shot in the dark but have you tried upgrading to PnP.PowerShell v1.11?

[jmartncp]

@jmartncp bit of a shot in the dark but have you tried upgrading to PnP.PowerShell v1.11?

Yes I have. I actually tried both upgrading and downgrading. Neither made much of a difference though.

[CallumCrowley]

I'm pretty sure I encountered the exact same issue after I erroneously created a new function app on PS Core 7.2, I downgraded it to 7.0 and everything was fine then (though I know this information isn't helpful).

@veronicageek are there any plans for PnP PS to support this scenario?

[Rutger-Knijnenburg]

I had the exact same issue. Downgrading the Function App to use PowerShell 7.0 instead of latest (7.2) fixed this for me!

[jmartncp]

I had the exact same issue. Downgrading the Function App to use PowerShell 7.0 instead of latest (7.2) fixed this for me!

As I mentioned, this wasn't an option due to security facilities only present in 7.2. I suppose if you had the option you could do that, though I am not sure if I would consider that a 'fix'. Thanks for your thoughts though.

[gautamdsheth]

@jmartncp - can you try commenting out the Az modules from requirements.psd1 files and then load PnP PowerShell ? I think there might be some conflict between these modules.

[jmartncp]

@jmartncp - can you try commenting out the Az modules from requirements.psd1 files and then load PnP PowerShell ? I think there might be some conflict between these modules.

They were already commented out. I wasn't using them to begin with, I only had PnP as my single dependency. Azure functions still attempts to load particular modules, like the Microsoft.Extensions.Logging one you see in the screenshot.

[BaronSparky]

I am seeing exactly the same behaviour and error with 7.2 and Azure functions. Downgrading to 7.0 fixes it for me also but would prefer not to have to.

[Micael-stack]

omg!! They are deprecating P.S 7.0 in december and still we have this crap! All our azure functions will fail that is it?

[BaronSparky]

They won't fail as such, but the platform will be unsupported going forward.

[CallumCrowley]

This is certainly turning in to a bit of an issue. While you could continue running 7.0, some organisations will have policies regarding out of support software and may not allow you to continue using a solution which isn't fully supported. Does anyone know of a way to stipulate which version Microsoft.Extensions.Logging.Abstractions Azure Functions loads? (as a workaround)

[Micael-stack]

So I fixed it... by rebuilding Pnp.Powershell and Pnp.Framework. Updated refs to all Microsoft.Extensions.* from 2.2.0 to 3.0.3.0

PnP.Framework.csproj:

PnP.PowerShell.csproj:

I rebuilded a local module and uploaded it to my Azure function, so no more managed dependencies... referencing directly the module in scripts.

[Micael-stack]

So it is concluding that Pnp.Powershell should upgrade microsoft.Extensions.* dependencies in project. There is no impacts moving from 2.2.0 to 3.0.3.0...

[CallumCrowley]

@Micael-stack what testing have you done to conclude that there is no breaking changes in upgrading the extensions?

Of course, upgrading the extensions would solve this issue but doing this could inadvertently introduce other bugs relating to wherever these dependencies are used in the PnP solution.

[Micael-stack]

Our module is used in multiple client services for site provisioning creation from teams to communication sites with full assets. I would not say that I am covering 100% cases but from my point with my dev Team it does the trick.

[BarasG]

I am experiencing the same issue. Downgrading to PowerShell version 7.0 fixes the issue, but this can only be a temporary solution since we have to upgrade to 7.2 by December 3th 2022. Our customer won't allow out of support software running on their tenant.

[CallumCrowley]

@BarasG yes, I raised this concern above. PnP.PowerShell is probably used in countless Azure Functions, surely this means every single one of them would be in an unsupportable state from Microsoft's viewpoint on December 3rd 2022.

[jebalert]

Confirmed this was the fix for me as well.. downgrading to runtime 7.0.

[frompedro]

Downgrading to PS 7.0 did it

[frankyvc]

+1 I'm experiencing the same issue with PowerShell 7.2

[astenman]

+1, Me too

[Kevinhebertd]

Same issue on Powershell 7.2 on Azure functions

[arjenbloemsma]

I'm facing the same issue. Downgrading solves it for now, but I hope the PnP team has time to provide the real fix soon, so we all can benefit from PowerShell 7.2.

@erwinvanhunen any timeline?

[StevenDerveaux-DnDCore]

I'm also facing this issue but cannot downgrade to PowerShell 7.0 because I use the Powershell module 'AzureAD'. That module requires the use of TLS 1.2 or higher. So, upgrading from 7.0 to 7.2 solves the new TLS requirements for AzureAD but breaks the Connect-PnPOnline cmdlet... Really, really annoying since the fact that some production Azure Functions are just not working anymore...

[oufly]

+1, the same for us

[StevenDerveaux-DnDCore]

@gautamdsheth , do you have any idea if the pnp.powershell is adapted on this issue or when it will happen?
Thanks for your feedback!

[gajcowan]

Do we expect the fix to also be rolled out at the same time to Azure Function Core Tools as we get the same issue with 4.9.495 x64, which means it is not possible to test locally before deployment.

The DLL Hell, if I remove the "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.2" statement from my settings it works, the MSGraph PowerShell modules no longer longer work due to a different DLL issue!!!!!

[Ofer-Gal]

How were you able to delete the "FUNCTIONS_WORKER_RUNTIME_VERSION"?
I only see it as a dropdown with 7.0 and 7.2 options.
Is there a file I can edit anywhere?

[myatix]

How were you able to delete the "FUNCTIONS_WORKER_RUNTIME_VERSION"? I only see it as a dropdown with 7.0 and 7.2 options. Is there a file I can edit anywhere?

@Ofer-Gal What are you trying to achieve? To role back to version 7.0 you can use a PowerShell script.

# Configure App to use .Net Core 7.0
$SubId = "<SubScriptionID>"
$ResourceGroupName = "RGXXX"
$AppName = "func-AppName"
$TenantID = "TenantID"

Connect-AzAccount -Tenant $TenantID -SubscriptionId $SubId

Set-AzContext -Subscription $SubId | Out-Null

Set-AzResource -ResourceId "/subscriptions/$SubId/resourceGroups/$ResourceGroupName/providers/Microsoft.Web/sites/$AppName/config/web" -UsePatchSemantics -Properties @{ powerShellVersion = '~7' } -Force

# Restart your app for the version changes to take effect
Restart-AzFunctionApp -Name $AppName -ResourceGroupName $ResourceGroupName -Force

# Verify that version was updated
$app = Get-AzFunctionApp -Name $AppName -ResourceGroupName $ResourceGroupName 
$app.SiteConfig.PowerShellVersion

Or you can see the FUNCTIONS_WORKER_RUNTIME_VERSION locally in VSCode in the local.settings.json file.

[Ofer-Gal]

I thought you removed it altogether.
I got it back to 7.0 with the script too. but it still errors on simple update.
[Error] EXCEPTION: The collection has not been initialized. It has not been requested or the request has not been executed. It may need to be explicitly requested.

[myatix]

@Ofer-Gal On your connection string have you remembered to add the parameter -returnconnection?

[Ofer-Gal]

I did.

[sli701]

As of 2023-01-12. the issue persists. And there is no option to go back to PowerShell 7.0.

[myatix]

@sli701 You can use the powershell script above to rollback to powershell core 7.0 on your function spp.

[sli701]

@myatix , was able to give a try on the Cloud Shell, it is able to rollback. not sure why it is not working when using Local Power Shell Command. However, it does work on the cloud shell, thanks for the help!

[gabbsmo]

@Francisco-Gamino Has the fix for Azure Functions been released? If yes, is it available in the West Europe region?

[Francisco-Gamino]

The Functions release with the fix for the PowerShell 7.2 language worker has been delayed. Currently, the release is set to start deploying on January 17th, 2023 and it is expected to be completed in one or two weeks if no blocking issues are found. I will continue to update this issue with the deployment status as more information becomes available. Thank you.

The Functions version 14.15.1 deployment that was supposed to start on 1/17/23 has been delayed. However, the deployment started rolling out today 1/23/23, and it is expected to be completed by the beginning of next week if no blocking issues are found.

/cc @anirudhgarg @AnatoliB @MadhuraBharadwaj-MSFT @michaelpeng36 @VpOfEngineering

[VpOfEngineering]

Hi everyone, we're still facing delays in rolling out 4.15.1. We will keep updates here as we fix the issues and continue the rollout. Thank you all for your patience.

[karthikramasubramanian]

Hi everyone, we're still facing delays in rolling out 4.15.1. We will keep updates here as we fix the issues and continue the rollout. Thank you all for your patience.

Do we have any update on when we can expect the rollout of '4.15.1'

[VpOfEngineering]

Barring any issues, we should be fully rolled out by the beginning of next week.

[Clam-]

Will any action need to be taken? Will our currently failing Azure Functions start working again next week without interaction?
Thank you.

[svermaak]

Will functions where a workaround was applied stop working? Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Clam- ***@***.***> Sent: Tuesday, January 31, 2023 2:37:26 PM To: pnp/powershell ***@***.***> Cc: svermaak ***@***.***>; Comment ***@***.***> Subject: Re: [pnp/powershell] [BUG] PnP and Azure functions assembly conflict. Could not load type 'Microsoft.Extensions.Logging.Abstractions.Internal.NullScope' from assembly 'Microsoft.Extensions.Logging.Abstractions' (Issue #2136) Will any action need to be taken? Will our currently failing Azure Functions start working again next week without interaction? Thank you. — Reply to this email directly, view it on GitHub<#2136 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC5RDEFS5GWCNNYKOSN63UDWVCCHNANCNFSM53M6HTGQ>. You are receiving this because you commented.Message ID: ***@***.***>

[Francisco-Gamino]

The PowerShell 7.2 language worker which is being deployed with 4.15.1 updates Microsoft.Extensions.Logging.Abstractions to version 6.0.3. If the workaround was applied to the PowerShell 7.0 language worker, then this should continue to work as no changes has been introduced to this version given that it has reached EOL.

@KoenZomers -- Could you please comment on next steps after 4.15.1 completes rolling out? Thank you.

[gautamdsheth]

Just tested this in an environment which has version 4.15.x.x , works perfectly fine !

To fix this issue in your environment, please wait till the fix is there. I am guessing it will be available very soon worldwide.

I tested this in a resource group which is in North Europe region.

Once the fix is available, you will need to update the PnP PowerShell to the latest nightly builds.

You need to explicitly specify the version number like 2.0.1-nightly or later.
The code will keep working as it is.

Once a major release of PnP PowerShell is done, you can also specify it as a wildcard entry 2.x

[thunderstorm654]

It would be good to know when the next major release of PnP will be out that works with the Azure fix. Some clients don't like to use nightly versions in production :) thanks!

[Clam-]

Just tested this in an environment which has version 4.15.x.x

How does one know if their environment is 4.15.x?

You need to explicitly specify the version number like 2.0.1-nightly or later.

How does one do this?

Thank you.

[gautamdsheth]

@Clam-

It is in the Azure function overview page:

You can specify the version of PnP PowerShell here:

App Files > Requirements.psd1 file

[gyadav-HBS]

As a workaround, my Azure functions were working fine with PS 7.0. and PnP.PowerShell 1.2. To test the above fix I updated the functions to use PS 7.2 and switched PnP.PowerShell to 2.0.6-nightly. And I am seeing the following exception now when making a call to New-PnPWeb. Any thoughts??

ERROR: System.Net.Http.HttpRequestException: Error while copying content to a stream. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.. ---> System.Net.Sockets.SocketException (10054): An existing connection was forcibly closed by the remote host. --- End of inner exception stack trace --- at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken) at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16 token) at System.Net.Security.SslStream.EnsureFullTlsFrameAsync[TIOAdapter](TIOAdapter adapter) at System.Net.Security.SslStream.ReadAsyncInternal[TIOAdapter](TIOAdapter adapter, Memory`1 buffer) at System.Net.Http.HttpConnection.FillAsync(Boolean async)
.................................
.................................

[jrudley]

If you are not running a consumption plan, but under an app service plan, I ran into a weird issue and found a workaround. I was on a B2 sku and kept getting the nullscope error. I was not downgrading my ps version due to other production functions running on the same app plan. Maybe Azure gov does not back patch existing hosts or not fully finished yet. To make it work, upgrade your plan to a PV2/V3 and it will move it to a new host which should have the patched runtime. I verified it worked, then moved it back to a B2 plan which was put on a host that was patched as well.

[desmay]

@Francisco-Gamino Do we know if 4.15.1 Azure function updates were pushed to Azure Gov ?

[gautamdsheth]

Going to close this issue. It has been fixed from Microsoft side when using Az function 4.15.x or later version. To use PnP PowerShell, as we mentioned, please use the latest 2.x.x-nightly builds.

@desmay - no idea if this has been fixed for Azure Gov, but you can reach out to Microsoft support/PG for more information on this.

We have no ETA on the major release of PnP PowerShell as of now.

[karthikramasubramanian]

Hi All, I recently upgraded PnP.Powershell from the 2.x.x-nightly to 2.1.1 and can confirm that it is working fine. I have deployed it to our prod tenant for almost a month now so far no errors or issues.. Regards Karthik Ramasubramanian Senior Digital Productivity Developer Norton Rose Fulbright Canada LLP / S.E.N.C.R.L., s.r.l. 45 O'Connor Street, Suite 1500, Ottawa, ON K1P 1A4, Canada T: +1 613.780.8674 | M: +1 613.277.2840 | F: +1 613.230.5459 ***@***.******@***.***> NORTON ROSE FULBRIGHT From: Fringie ***@***.***> Sent: May 18, 2023 9:45 AM To: pnp/powershell ***@***.***> Cc: Karthik Ramasubramanian (he/him/his) ***@***.***>; Comment ***@***.***> Subject: Re: [pnp/powershell] [BUG] PnP and Azure functions assembly conflict. Could not load type 'Microsoft.Extensions.Logging.Abstractions.Internal.NullScope' from assembly 'Microsoft.Extensions.Logging.Abstractions' (Issue #2136) [External Email – Use Caution] Any update on this? Going to close this issue. It has been fixed from Microsoft side when using Az function 4.15.x or later version. To use PnP PowerShell, as we mentioned, please use the latest 2.x.x-nightly builds. @desmay<https://github.com/desmay> - no idea if this has been fixed for Azure Gov, but you can reach out to Microsoft support/PG for more information on this. We have no ETA on the major release of PnP PowerShell as of now. I am getting this issue with: Azure Functions Core Tools Core Tools Version: 4.0.5148 Commit hash: N/A (64-bit) Function Runtime Version: 4.17.3.20392 Can you advise? — Reply to this email directly, view it on GitHub<#2136 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKJU7QZIEUY6ZD42RJIHA6LXGYRVVANCNFSM53M6HTGQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>> Law around the world Le droit à l’échelle mondiale nortonrosefulbright.com CONFIDENTIALITY NOTICE: This email is confidential and may be privileged. If you are not the intended recipient please notify the sender immediately and delete it. AVIS DE CONFIDENTIALITÉ : Ce courriel est confidentiel et peut être protégé par le secret professionnel. Si vous n’en êtes pas le destinataire visé, veuillez en aviser l’expéditeur immédiatement et le supprimer.