[BUG] Assembly Conflicts with Microsoft.Graph Module #3637
Comments
|
I fixed this by grabbing the Microsoft.Graph.Core.dll from Microsoft.Graph.Authentication and dropping it right into C:\Program Files\PowerShell\Modules\PnP.PowerShell\2.3.8\Core Not the best, nor the most elegant solution, but it worked. |
Also grab the Microsoft.Identity.Client.dll from Microsoft.Graph.Authentication and replace the PnP version. This resolved Connect-MGGRAPH error trying to use the older dll files from the PnP module if it was called first. |
|
Thanks for the suggested workarounds - I'll be sure to test those. I am concerned about the lengthy regression testing that might be required by replacing these, as I'm not sure if the replaced DLLs will cause issues with the rest of my code. |
|
As an update to my previous post, I have tried the DLL replacements as indicated above. While this resolves the authentication issue, calling other Graph cmdlets (such as Get-MgUser) reveals other assembly conflicts
Unfortunately, we are at a crossroads in getting utility out of both PnP.PowerShell and Microsoft.Graph. |
|
One final update - I think I may have found a valuable workaround tool, and it's built in: I was just able to pull Users and Applications from Graph API without any assembly conflicts. I did not know this cmdlet exists, but it seems like an excellent workaround. A quick sample of a couple commands I ran Hopefully this helps someone else! |
|
The issue persists with the new version of graph (2.12.0) and PNP 2.3.0, could you please fix this issue? otherwise people are forced to work with the old PNP version 1.12.0.
|
|
Any updates on this? |
|
Same issue here. Absolutely horrible bug tbh. |
|
Is there anything new? This is a really annoying bug. |
|
Add me to the list of people who are experiencing this issue. Brand new server with the lastest versions of PNP and Graph modules. There's gotta be a way to fix this. Seems both Graph and PNP teams are blaming the other team rather than coming up with a solution. |
|
Is there a timeline for this? Also facing this issue with workaround not feasible :/// |
|
Any update here? As of now, we have to run a single server with PnP.Powershell 2.3.0 and version 1.28 of the Mg-Module. |
|
Our automation scripts are also failing with the same error and for the same reason. Another short-term (not ideal) workaround for using PnP 2.3 is to uninstall the MS Graph module and/or install Microsoft.Graph 2.8. This DLL version conflict needs to be resolved in way that it doesn't keep happening every few updates. |
|
Same issue for me in Azure Automation with PnP.PowerShell 2.4.0 and Microsoft.Graph 2.15.0 |
|
A method that worked for me was to connect to Graph, make a call and then connect to PnP. This is the quick test that I did and have been using the same session for PnP and Graph calls. |
|
Facing same issues here, my workflow is that I get information from Sharepoint with PNP Powershell and then connecting to Graph, this is not working properly for obvious resons. Seems like there are quite a few people that are facing the same issues here. Have tried to use some workarounds but have not got anything to work except to use really old versions of either Graph (1.25) or go back to PNP Powershell version 1.x. That should not be the solution to this issue. |
|
@dennis,
My workaround is still working. I currently have a session open to
SharePoint, Graph, and EXO and haven't had any issue. The main thing is
that the Graph commands are executed first. Pnp then uses that token
provider in preference to the one bundled with it.
Kind regards,
Kevin
-------------------------------
If you're going to be passionate about something, be passionate about
learning
…On Thu, 14 Mar 2024 at 19:46, Dennis Johansson ***@***.***> wrote:
Facing same issues here, my workflow is that I get information from
Sharepoint with PNP Powershell and then connecting to Graph, this is not
working properly for obvious resons.
Seems like there are quite a few people that are facing the same issues
here. Have tried to use some workarounds but have not got anything to work
except to use really old versions of either Graph (1.25) or go back to PNP
Powershell version 1.x.
That should not be the solution to this issue.
—
Reply to this email directly, view it on GitHub
<#3637 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGVVB6ZWTHV2UXQRTJ6FSLYYFWW5AVCNFSM6AAAAABAW5IDHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXGA2DGMJSGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Keep in mind, that writing @ notifies that user of your message :) |
The workflow i'm running does not support that since I have to go to SharePoint first and that breaks everything. This should not be a issue and should be fixed so both of the modules can be used and used in what order needed for the current workflow. |
|
+1 |
|
This is so stinking frustrating..... Someone please explain why "Connect-MgGraph" loads Pnp.Powershell assemblies? |
|
@kpinel -- Are you using Visual Studio Code or running scripts from pwsh.exe? If I have the Pnp.PowerShell module installed, I can't even Connect-MgGraph - I get the same error as the OP. If I uninstall Pnp.PowerShell my Connect-MgGraph works fine. |
|
It doesn't matter. It's PowerShell regardless.
Also, graph doesn't load PNP assemblies. They both use the same assemblies.
Graph happens to use the newer ones so if you connect to graph first, the
PNP modules won't load the older assemblies included with it.
…On Sat, 13 Apr 2024, 06:06 jgriff500, ***@***.***> wrote:
@kpinel <https://github.com/kpinel> -- Are you using Visual Studio Code
or running scripts from pwsh.exe?
If I have the Pnp.PowerShell module installed, I can't even
Connect-MgGraph - I get the same error as the OP. If I uninstall
Pnp.PowerShell my Connect-MgGraph works fine.
—
Reply to this email directly, view it on GitHub
<#3637 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGVVB3SR6GX6D4VNF2YUCTY5A5EHAVCNFSM6AAAAABAW5IDHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJSGQ2TENZSG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@kpinel my experience sounds slightly different. From Visual Studio Code, Connect-MgGraph fails if PnP.PowerShell is installed (without importing or issuing any commands). I can do a fresh PS session, Connect-MgGraph and see there are Pnp.PowerShell assemblies loaded. If I uninstall Pnp.PowerShell, Connect-MgGraph works perfectly. I have a script that uses MgGraph and PnP.Powershell -- if I run from PS 7 (right click, open with PWSH), my experience mimics others -- run Connect-MgGraph first, run a Mg-Get command, THEN import PnP.Powershell. |
|
I had the same issues and (for a workaround) wrote a PowerShell script to fix two known issues between the PnP.PowerShell and Microsoft.Graph.Authentication modules. If interested, read Resolve-TAPnPPowerShellConflicts in my repository. |
Thank you, this solved my pain and agony in trying to figure out a way to make both pnp and graph modules work in 1 script! |
@TobiasAT -- huge props for this. Great workaround. Thank you!! |
|
We also have this issue. In my test environment I can confirm this combination of modules will fail with the error below. Azure Automation PS 7.2 Runtime Environment modules. This is a custom runtime environment. Runbook output: It doesn't matter what order modules are loaded in the runbook. In an older AA environment we have, the system-generated runtime environments are different and luckily the 7.2 runtime has the old 1.25.0 graph module still in it along with pnp 2.x.0 (hopefully I remembered this accurately, system-generated runtimes give the version simply as "Custom" with a date and size. All modules are from a year ago); automations here still work for the moment. Still, they are using old versions which is not ideal long-term. I don't want to compromise on security by having runbooks run on-prem on self-hosted runners if they don't need to touch on-prem resources. If I did this, I would have to use cert-based app reg auth and a non-standard pnp module which may cause other issues down the line. In Azure Automation runtime environments, it may be a case of uploading a custom version of the pnp module with the offending Microsoft.Graph.Core files removed as per the workaround from @TobiasAT (great writeup, thanks mate). I haven't tested this and runtime environments are still in preview so implementation could change. Keen to hear any updates/experiences in AA for this issue. Thank you |
|
@TobiasAT Get-PnPSiteTemplate: D:\TFS\SWO.PortalServices\Customer Creation\Export-SwoPortalTemplate.ps1:161
Line |
161 | Get-PnPSiteTemplate -Out $fullPath -Schema LATEST -Encoding ([Sys …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Unable to load one or more of the requested types. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral,
| PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0,
| Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core,
| Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly
| 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file
| or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could
| not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file
| specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot
| find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The
| system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral,
| PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0,
| Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core,
| Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly
| 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file
| or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could
| not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file
| specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot
| find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The
| system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral,
| PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0,
| Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly 'Microsoft.Graph.Core,
| Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file or assembly
| 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could not load file
| or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. Could
| not load file or assembly 'Microsoft.Graph.Core, Version=1.25.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file
| specified.
Write-Error: XML does not exist. Error during site template export.I really don't know what the problem is to update the dll within PnP... |
@Roladin |
The same with |
|
Unfortunately, I can confirm @HeKr09 issue with the Invoke-PnPSiteTemplate cmdlet... |
|
@nicole-ge thanks, good point. MS Graph REST API with PnP is a decent option at the moment for Azure Automation. If my weird system-generated runtime environment breaks I might have to go down that path :) |
|
Anyone from the PnP team available to comment on this issue? |
|
I can confirm this bug. :( |
|
Just to reiterate, this is EXTREMELY ANNOYING. Please PNP team. |
|
I guess they could port it to use Assembly Load Context (ALC) but that would require a TON of porting work. I am not even sure if there is a proper different way - because without ALC you will always conflict with some Versions of other Modules that target a different Dependency Version... And as this is a non official/Open Source module i don't even know if it's realistic to hope that this will be implmented someday :/ |
Thank you so much Tobias! I had the same problem using MS Graph module and PnP in same script, but now fixed with your resolution! |
|
PnP.PowerShell module has been updated to version 2.5 last Thursday. I checked known conflicts with the updated module.
|
|
@HeKr09 For your case, or if the command requires the Microsoft.Graph.Core.dll from PnP.PowerShell module, you may have to split your script into two separate processes. One process uses just the Microsoft.Graph.Core.dll from PnP.PowerShell module, the other the updated Microsoft.Graph.Core.dll version. If you mix the different versions of Microsoft.Graph.Core.dll in one process, the script will have conflicts again. |
|
I had a conflict between the powershell Graph and ExchangeOnline modules. I downgraded the ExchangeOnline to version 3.4.0 and it resolved the conflict. |
|
@vnerdahl What version of Graph are you using? I'm not having any issues using EXO 3.5.0 and Graph 2.19.0 together |
|
|
For anyone looking for a workaround to use the PnP module and the Graph module in the same script, one way is to start a separate job within a script that encapsulates the import of one of the modules and run any of that module's cmdlets within it. For example, in the case where most of your logic lies on GraphAPI side, but you want to first get some sites from SharePoint, you can try the following solution: $pnpJob = Start-Job -ScriptBlock {
Import-Module PnP.PowerShell
#Get all sites using PnP
$tenantUrl = "https://tenant-admin.sharepoint.com"
Connect-PnPOnline -Url $tenantUrl
$allSites = Get-PnPTenantSite
return $allSites
}
#Run PnP operations in a separate job
$allSites = Receive-Job -Job $pnpJob -Wait
Remove-Job -Job $pnpJob
#Connect to MS Graph
Connect-MgGraph
#Rest of graph logic... E.g.
$allSites | ForEach-Object {
Get-MgSite -Search $_.Url
} |
|
Thank you for the good workaround. It is very suitable for some cases, rather difficult to implement in others. |
|
My workaround is to delete Microsoft.Graph.Core*.dll from the PnP module which is easy on a PC/Server. Not so much in automations. |
|
You cannot handle too much the modules if you use the requirements.psd1 file unless you download both module in the modules folder and upload it with your zip file, which is not nice. What I did so far, is that I always connect to mgraph prior to connect to pnp-online. Connect-MgGraph -ManagedIdentity -NoWelcome This way, the right assembly is loaded. I did that for all my scripts in my Azure functions that are in the webapp. I agree with @veronicageek , managing the assembly dependency is a nightmare between Az/Graph/PnP |
|
I am also facing this issue with PnP 2.12.10 and latest Mg modules. |
|
Hi @sabey2000 Does your example also work within Azure Automation Runbook? |
Yes, you have to connect to Microsoft Graph prior doing anything. This will force the assembly to load and PnP will use it. The opposite will not work. The issue with Azure Automation Runbook and Azure Function is that the powershell runtime is not restarted for each call. You run in the same powershell. So if a script connect to PnP and later another wants to connect to Graph it will fail. |
|
Hello everyone, I had the same issue, and I used multiple stable versions of PnP and MS graph. To resolve the issue,
[with pnp and MS graph latest versions] I was facing the issue because, the env var in PowerShell extension: 'PSExecutionPolicyPreference Bypass' The problem resolves for me with this approach, this might not work for you |
You sir, are a legend! I have been fighting this issue for days and couldn't get it working whatever order I used PnP and Graph in. Thank you so much for writing this and sharing it 🙏 |
and others
Reporting an Issue or Missing Feature
Running Microsoft.Graph cmdlets, such as Connect-MgGraph and Get-MgApplication, produce an assembly conflict error if run after PnP.PowerShell assemblies have already been loaded.
Expected behavior
According to release notes for PnP.PowerShell 2.3.0, assembly conflicts have been resolved. With this being true, I was hopeful I could develop a script that used cmdlets from both PnP.PowerShell and Microsoft.Graph. In my scenario, this doesn't appear to be the case.
Actual behavior
Results from trying to run Connect-MgGraph and Get-MgApplication after PnP had already been loaded:
Output of assemblies loaded in the session. The two assemblies called out in the MgGraph exception are sourced from the PnP.PowerShell Module
Steps to reproduce behavior
What is the version of the Cmdlet module you are running?
PnP.Powershell - 2.3.3 Nightly Build
Microsoft.Graph.Authentication - 2.9.0
Microsoft.Graph.Applications - 2.9.0
Which operating system/environment are you running PnP PowerShell on?
The text was updated successfully, but these errors were encountered: