Een nieuwe oplossing? Zeker niet

Natuurlijk is hierbeneden genoemde oplossing al lang bekend in de Github community. Wat nieuw was voor mij is dat zelfs bij een mislukt , per ongeluk getypt commando uit de pnp module PNP’s graph core al in het geheugen geladen wordt en daar de zaak blokkeert voor de module die je eigenlijk had willen gebruiken.

Hoe ik er vandaag tegenaan liep

Ik maak verbinding met Microsoft Graph. Alles lijkt prima:

Ik wil even checken of ik in de juiste tenant zit. Typ snel:

PnP geeft een error: "Not connected to SharePoint". Logisch, ik ben niet ingelogd met PnP. Geen probleem toch? Ik typ het goede commando:

BOOM. Crash.

Wacht... Version=1.25.1.0? Dat is PnP's versie. Door die ene typefout heeft PnP zichzelf geladen, inclusief Graph Core 1.25.1.0 En nu zit Graph vast. De benodigde types zitten niet in Graph Core 1.25.1.0

Oplossing? Sessie opnieuw starten en opnieuw beginnen. Weer 5 minuten kwijt.

De volgorde maakt alles uit

Het valse gevoel van veiligheid

1. Connect-MgGraph alleen is NIET genoeg. Ja, je bent ingelogd. Ja, je hebt een token. Maar de Graph Core 2.x assemblies zijn nog niet geladen. PowerShell wacht met lazy loading tot je écht iets met Graph doet.

2. Type je per ongeluk een pnp commando in plaats van Get-MgContext? Game over. PnP denkt "ah, ik word geroepen!" en laadt zichzelf inclusief Graph Core 1.25.1.0, want het ziet geen andere. Zelfs als het commando faalt omdat je nog niet ingelogd bent met PnP, is de schade al aangericht.

3. Nu voer je een Graph-commando uit zoals Get-MgOrganization of Get-MgUser. Graph wil zijn Core 2.x laden want daar ziotten de benodigde types in, maar vindt Core 1.25.x al in het geheugen. Boom. Assembly conflict. Foutmelding. Frustratie.

De volgorde die wél werkt

Pas na het uitvoeren van een Graph-commando zijn de Core 2.x assemblies daadwerkelijk geladen. Vanaf dat moment kan PnP zich er bij neerleggen en werkt alles.

Waarom Remove-Module een illusie is

Denk je het op te lossen met Remove-Module PnP.PowerShell -Force? Vergeet het maar. De assemblies blijven in het PowerShell AppDomain zitten als beton. De enige remedie:

Sessie sluiten. Opnieuw starten.

De venijnige types

Je kunt op drie manieren in de val lopen:

Type 1: De haastige verbinder

Type 2: De typo (mijn ervaring van vandaag)

De foutmelding die je dan krijgt:

Zie je die Version=1.25.1.0? Dat is PnP's versie. Graph wil types gebruiken die alleen in Core 2.x bestaan, maar PowerShell zit vast aan de 1.25.1.0 die PnP al geladen heeft.

Type 3: De optimist

De moraal

PowerShell is geen democratie. De eerste module die een Graph Core assembly laadt, regeert ongevraagd de sessie.

De gemene twist: authenticatie is voor Microsoft Graph niet hetzelfde als assembly loading. Je kunt perfect ingelogd zijn in Graph zonder dat de cruciale assemblies geladen zijn.

Tot Microsoft Graph en PnP.PowerShell hun huwelijkstherapie afronden, is er maar één regel:

Eerst Graph verbinden EN een commando uitvoeren, dan pas PnP.

#PowerShell #MicrosoftGraph #PnPPowerShell #Microsoft365 #SharePoint #TechTips