[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. (/api/)
• 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
• [X] 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!

[ekdegerman]

We just ran into this same issue when trying to get our functions upgraded before the December 3rd deprecation of 7.0. It would really help to understand if/when we can expect a fix to be released.

[brandilton]

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 - can you give a bit more detail on where I could find these files to modify and where they would need to be uploaded? I'm somewhat familar with Kudu for doing this type of thing, but am not seeing PnP.PowerShell.csproj or PnP.Framework.csproj anywhere.

[wrongecho]

Running into this error as well. Downgrading to 7.0 is a workaround but definitely not a resolution as support is being depreciated.

[gautamdsheth]

Hello all on this thread, we are looking into fixing this for Azure functions. Is more complex than we initially thought. It is surely at the top of our minds and a priority issue for us. Will try to fix it asap but can't provide an ETA at this point.

[svermaak]

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 - can you give a bit more detail on where I could find these files to modify and where they would need to be uploaded? I'm somewhat familar with Kudu for doing this type of thing, but am not seeing PnP.PowerShell.csproj or PnP.Framework.csproj anywhere.

@Micael-stack Do you mind sharing project and binaries?

[thunderstorm654]

+1 to needing a solution for this. Our clients will not allow use of unsupported versions in production so we're under pressure to resolve this ASAP before December and can't stay on 7.0. Heavy usage of PnP PowerShell so rebuilding not an ideal scenario. Any more details on whether @Micael-stack's approach is at all plausible?

[Micael-stack]

Hi, I have created a pull request. I did a fork too, if it isnt approved so here it is :

https://github.com/Micael-stack/powershell/tree/fix/support-powershell7.2-azure-function

Instructions to get your own files :

1. Clone the git branch mentionned here

2. Run the powershell script in ".\Build\Build-Debug.ps1" . .\Build\Build-Debug.ps1

3. At the end of the script, there should be a module folder in your Documents/Powershell/Modules/Pnp.Powershell

4. Zip it, and upload it to your azure function, if not in git push setup ( I use the powershell tool in azure portal and upload the zip here :

5. Reference the powershell module in your code like this : Import-Module .\Pnp.PowerShell\PnP.PowerShell.psd1

That's it, you should be running with no problems!

• You cannot use anymore PNP.Powershell managed dependencies like this. Remove it if you do from requirements.psd1

Thanks!

[KoenZomers]

Thanks @Micael-stack for your efforts. We're currently working with the Product Group to see how this can be addressed on the Azure Function side. Lowering our version references is not sustainable in the long run as the .NET versions should be aligned for optimal performance and stability. The PG is currently looking at how they can change Azure Functions to fix this on their side.

[Micael-stack]

@KoenZomers That is why my pull request, to raise Pnp.PowerShell to use newer package versions to be compatible with Azure function, who is at a later version with packages.

[KoenZomers]

I see. Thanks for elaborating. For the current version that might work, but we're aiming to go for .NET 6 support in the next version and there this would not be an option. I'll discuss it in our team if we could apply your suggestion in the meantime.

[Micael-stack]

I did myself a version with PnP.Core and PnP.Framework locally built with .NET 6 and i did upgrade the packages (Microsoft.Extensions.Logging.Abstractions and others) to the 3.0.3.0, and did test PnP.PowerShell with a build .Net6 profil too and everything seemed working (building the projects, not going farther though...)!

@KoenZomers I hope you guys can come up with the .NET 6 support soon! What a nice chrismas present.... ;)

[thunderstorm654]

@KoenZomers if the solution proposed by @Micael-stack is suitable while you work with the PG and towards .NET 6 that would make a lot of us very happy!

[BeekvanV]

We're experiencing this issue as well. seeing as PS7.0 will be deprecated in a week or so I hope this issue gets appropriate attention.

[KoenZomers]

No worries @BeekvanV, we're working closely with the Product Group for a solution on this. We're currently testing a resolution for this internally. Thus far things are looking well. It will not be that your current Azure Functions will stop working on December 3rd. The permanent resolution for this will follow in January or February as things look like now.

[jukka76]

Hi @KoenZomers!

It will not be that your current Azure Functions will stop working on December 3rd.

Could you clarify? Does this mean that we can safely ignore the error message and continue using PS7.0 until resolution is available and we can safely switch to 7.2? In that case please update the date in deprecation message in Azure. Just making sure our prod environment does not stop working suddenly

[Henry-Sir]

Hi, I have created a pull request. I did a fork too, if it isnt approved so here it is :

https://github.com/Micael-stack/powershell/tree/fix/support-powershell7.2-azure-function

Instructions to get your own files :

1. Clone the git branch mentionned here
2. Run the powershell script in ".\Build\Build-Debug.ps1" . .\Build\Build-Debug.ps1
3. At the end of the script, there should be a module folder in your Documents/Powershell/Modules/Pnp.Powershell
4. Zip it, and upload it to your azure function, if not in git push setup ( I use the powershell tool in azure portal and upload the zip here :
5. Reference the powershell module in your code like this : Import-Module .\Pnp.PowerShell\PnP.PowerShell.psd1

That's it, you should be running with no problems!

• You cannot use anymore PNP.Powershell managed dependencies like this. Remove it if you do from requirements.psd1

Thanks!

@Micael-stack Is it possible to upload your build? I have created a build according to your instructions, unfortunately it does not work.

ERROR: The system cannot find the file specified.Exception :Type : Internal.Cryptography.CryptoThrowHelper+WindowsCryptographicExceptionTargetSite :Name : FilterPFXStoreDeclaringType : Internal.Cryptography.Pal.CertificatePal, System.Security.Cryptography.X509Certificates, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3aMemberType -> Connect-PnPOnline -CertificateBase64Encoded $azureCertBase

@KoenZomers

It will not be that your current Azure Functions will stop working on December 3rd.

See jukka76 post. What does this mean for us?

[srnlekkala]

pnp.powershell 1.7.0 is supporting with powershell 7.2 and higher versions giving the reported error. until the fix comes to continue to support after 3rd Dec, we can use this solution. If the requirement is to use higher version of pnp.powershell then downgrading powershell version to 7.0 is the workaround.

[Henry-Sir]

pnp.powershell 1.7.0 is supporting with powershell 7.2 and higher versions giving the reported error. until the fix comes to continue to support after 3rd Dec, we can use this solution. If the requirement is to use higher version of pnp.powershell then downgrading powershell version to 7.0 is the workaround.

No, version 1.7.0 does not work either, see screnshot below.

I tested some more and the fix from @Micael-stack works. Only the login (Connection-PNPOnline) via certficate does not work. Via user/password, app ID / secret and acsses token works.

[KoenZomers]

@Francisco-Gamino can you comment on the rollout of the updated Azure Functions in January and the situation between now and then with PowerShell 7.0 Azure Functions being deprecated?

[Micael-stack]

@Henry-Sir Hi, sorry for the delay. Yep ok just testes with the fork I did, since Pnp.Powershell 1.12 my fix stopped working. Sorry for that. I will have to try another way but running out of time!

I will try to save up some time this week or the next to bend my head over it.

[Ofer-Gal]

I have the same issue in Azure using 1.12.0 on a function that I could only use PowerShell 7.0 (no other option) The error is on a statement: $appConn = Connect-PnPOnline -Url $appUrl -Tenant $env:TenantId -ClientId $env:ClientId -CertificateBase64Encoded $env:CertificatePFX -CertificatePassword $CertificatePassWord -ReturnConnection Should I downgrade to 1.10.0 or maybe less? Is there another fix? Also, this instance runs in Premium plan. when it ran in consumption I did not have the issue.

[Francisco-Gamino]

@Francisco-Gamino can you comment on the rollout of the updated Azure Functions in January and the situation between now and then with PowerShell 7.0 Azure Functions being deprecated?

The PowerShell 7.2 language worker with the fix will start rolling out January 3rd, and it is expected to complete in one or two weeks. In the meantime, we are committing to provide support for the apps that are on PowerShell 7.0 until this deployment completes.

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

[Ofer-Gal]

I set the PowerShell to 7.0 and it works now. But I have a timeout issue. the plan is premium but I get a "Timeout value of 00:30:00 exceeded by function 'Functions.DailyMaintenance' " so paying more does not help? I have SCM_LOGSTREAM_TIMEOUT set to 43200 seconds Any ideas?

[wrongecho]

I set the PowerShell to 7.0 and it works now. But I have a timeout issue. the plan is premium but I get a "Timeout value of 00:30:00 exceeded by function 'Functions.DailyMaintenance' " so paying more does not help? I have SCM_LOGSTREAM_TIMEOUT set to 43200 seconds Any ideas?

30 mins is default for premium.

You need to adjust the functionTimeout parameter in host.json.

For premium functions the upper limit is technically unbounded, but Microsoft only guarantee 60 mins of continuous running (i.e it might be restarted after that time, so needs to handle that gracefully).