powershell
powershell copied to clipboard
pnp
[BUG] PnP and Azure functions assembly conflict. Could not load type 'Microsoft.Extensions.Logging.Abstractions.Internal.NullScope' from assembly 'Microsoft.Extensions.Logging.Abstractions'
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?
- [ ] Windows
- [ ] Linux
- [ ] MacOS
- [ ] Azure Cloud Shell
- [X] Azure Functions
- [ ] Other : please specify
@jmartncp bit of a shot in the dark but have you tried upgrading to PnP.PowerShell v1.11?
@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.
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?
I had the exact same issue. Downgrading the Function App to use PowerShell 7.0 instead of latest (7.2) fixed this for me!
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.
@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 - can you try commenting out the Az modules from
requirements.psd1files 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.
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.
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?
They won't fail as such, but the platform will be unsupported going forward.
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)
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.
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...
@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.
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.
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.
@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.
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?
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...
@gautamdsheth , do you have any idea if the pnp.powershell is adapted on this issue or when it will happen? Thanks for your feedback!
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.
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.
Running into this error as well. Downgrading to 7.0 is a workaround but definitely not a resolution as support is being depreciated.
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.