[BUG] Invoke-PnPSiteTemplate fails with "Could not load file or assembly 'Microsoft.SharePoint.Client.UserProfiles'" on 3.4.x when the template uses localization

Start by reading the assembly loading setup introduced for the private load context in #5393, then inspect LocalizationExtensions.CanUseAcceptLanguageHeaderForLocalization and TenantHelper.ProcessUserProfiles in PnP.Framework, which the report identifies as referencing UserProfiles types. Compare how 3.2.0 and 3.4.1 resolve the CSOM assemblies; done means localization templates can invoke the affected path without the reported assembly load failure.

Reporting an Issue or Missing Feature

Issue.

Expected behavior

Invoke-PnPSiteTemplate applies a template that uses <pnp:Localizations> and {resource:...} tokens, as it does with 3.2.0.

Actual behavior

On 3.4.0, 3.4.1 and the current nightly (3.4.65, 2026-10-24) the cmdlet fails:

Invoke-PnPSiteTemplate: Could not load file or assembly 'Microsoft.SharePoint.Client.UserProfiles, Version=16.1.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'. The system cannot find the file specified.

The DLL is present in the module's Core folder with the expected strong name. Templates without <pnp:Localizations> are not affected, which is probably why this has not been reported yet.

Steps to reproduce

1. PowerShell 7.6.6 (x64), PnP.PowerShell 3.4.1 (also 3.4.0 and nightly 3.4.65), fresh session, no other modules loaded.

2. A template with localization, for example:

   <pnp:Provisioning xmlns:pnp="http://schemas.dev.office.com/PnP/2022/09/ProvisioningSchema">
     <pnp:Localizations>
       <pnp:Localization LCID="1033" Name="English" ResourceFile="Resources.en-US.resx" />
     </pnp:Localizations>
     <pnp:Templates ID="T">
       <pnp:ProvisioningTemplate ID="T1" Version="1" Scope="RootSite">
         <pnp:SiteFields>
           <Field Type="Text" DisplayName="{resource:Field_Title}" ID="{9f6c8a43-0b58-4e7a-8c6a-2b3f3f1a7d10}" Name="PnPReproField" StaticName="PnPReproField" Group="Repro" />
         </pnp:SiteFields>
       </pnp:ProvisioningTemplate>
     </pnp:Templates>
   </pnp:Provisioning>
   

3. Connect-PnPOnline -Url https://<tenant>.sharepoint.com -Interactive -ClientId <id> and Invoke-PnPSiteTemplate -Path .\repro.xml.

Repro without a tenant. The failing code path is PnP.Framework.Provisioning.ObjectHandlers.Extensions.LocalizationExtensions.CanUseAcceptLanguageHeaderForLocalization(Web), which constructs a Microsoft.SharePoint.Client.UserProfiles.PeopleManager. Calling it through reflection shows the difference between versions without connecting:

Import-Module PnP.PowerShell
$fw   = [AppDomain]::CurrentDomain.GetAssemblies() | Where-Object { $_.GetName().Name -eq 'PnP.Framework' }
$csom = [AppDomain]::CurrentDomain.GetAssemblies() | Where-Object { $_.GetName().Name -eq 'Microsoft.SharePoint.Client' }
$m = $fw.GetType('PnP.Framework.Provisioning.ObjectHandlers.Extensions.LocalizationExtensions').GetMethod('CanUseAcceptLanguageHeaderForLocalization', [System.Reflection.BindingFlags]'Public,NonPublic,Static')
$ctx = [Activator]::CreateInstance($csom.GetType('Microsoft.SharePoint.Client.ClientContext'), [object[]]@('https://invalid.sharepoint.invalid'))
try { $m.Invoke($null, [object[]]@($ctx.Web)) } catch { $e = $_.Exception; while ($e.InnerException) { $e = $e.InnerException }; $e.Message }

Version	Result
3.2.0	SocketException (UserProfiles loaded, the method reached the network call)
3.4.0	Could not load file or assembly 'Microsoft.SharePoint.Client.UserProfiles ...'
3.4.1	same
3.4.65-nightly (2026-10-24)	same

Analysis

After Import-Module on 3.4.1, [System.Runtime.Loader.AssemblyLoadContext]::All shows:

• Default: PnP.PowerShell, Microsoft.SharePoint.Client, .Runtime, .Taxonomy, .DocumentManagement, .Publishing, .WorkflowServices
• PnP.PowerShell (the private context from #5393): PnP.Core, PnP.Framework

Microsoft.SharePoint.Client.UserProfiles, .Search, .Search.Applications and Microsoft.Online.SharePoint.Client.Tenant are not loaded at import, and neither context resolves them later: LoadFromAssemblyName on either context throws FileNotFoundException, although the files are in Core with the right identity. On 3.2.0, where everything lives in the default context, the runtime probes the module folder and finds them.

An IL scan of PnP.Framework.dll (3.4.1) finds exactly two methods that reference UserProfiles types: LocalizationExtensions.CanUseAcceptLanguageHeaderForLocalization and TenantHelper.ProcessUserProfiles. The first runs for every template with localization, so this affects anything provisioned with resx files. The same mechanism will hit Search/Tenant for templates that touch those areas.

This is not fixed by #5481 or #5482 (nightly 3.4.65 includes both). Not related to #5480 (no other modules loaded) and not caused by OneDrive or PowerShell version; verified with the module installed under both a OneDrive-synced path and a plain local path.

Workaround

Pre-load the CSOM assemblies into the default context after import:

Import-Module PnP.PowerShell
Get-ChildItem (Join-Path (Get-Module PnP.PowerShell).ModuleBase 'Core') -Filter 'Microsoft.*SharePoint*.dll' |
  ForEach-Object { [System.Reflection.Assembly]::LoadFrom($_.FullName) | Out-Null }

After this, both contexts resolve all ten CSOM assemblies and the reflection repro above reaches the network call on 3.4.1. Using 3.2.0 also works.

Environment

• PnP.PowerShell 3.4.0, 3.4.1, 3.4.65-nightly (also verified 3.0.0, 3.1.0, 3.2.0 work)
• PowerShell 7.6.6 (x64), Windows 11, .NET 10
• Module loaded from a plain local folder via Import-Module <path>\PnP.PowerShell.psd1, no other modules in the session