bin/net10.0/PSDataRepository.Loader.xml
|
<?xml version="1.0"?> <doc> <assembly> <name>PSDataRepository.Loader</name> </assembly> <members> <member name="T:PSDataRepository.Loader.EngineLoadContext"> <summary> The engine's <see cref="T:System.Runtime.Loader.AssemblyLoadContext"/>. Resolves every assembly the module ships from the module directory into this context, except: <list type="bullet"> <item><description>assemblies the module does not ship (PowerShell itself, the .NET runtime) — they come from the default context, where the host loaded them;</description></item> <item><description>assemblies the platform already provides in the same or a higher version — the platform copy wins, as it would in the default context.</description></item> </list> </summary> </member> <member name="F:PSDataRepository.Loader.EngineLoadContext.ModuleAssemblyFileName"> <summary>The assembly whose <c>.deps.json</c> describes the whole module payload.</summary> </member> <member name="M:PSDataRepository.Loader.EngineLoadContext.IsProvidedByPlatform(System.Reflection.AssemblyName)"> <summary> True when the host's trusted platform assemblies (the runtime and PowerShell's own folder) contain this assembly in at least the requested version. The module's copy is then redundant, and a second identity of a platform type would not be assignable to the one PowerShell uses. </summary> </member> <member name="T:PSDataRepository.Loader.ModuleEngine"> <summary> Hosts the module engine — the cmdlets, <c>Microsoft.Extensions.*</c>, Azure.Identity, MSAL, the storage clients and everything else the module ships — in an <see cref="T:System.Runtime.Loader.AssemblyLoadContext"/> of its own instead of the process-wide default one. <para> The default context holds exactly one assembly per name for the whole PowerShell process. A module that loads its third-party libraries there decides, for every other module in the same session, which version of those libraries exists: a module importing later that needs its own copy fails with "Assembly with same name is already loaded". Loading the engine into its own context leaves the default context to whoever needs it, in either import order. </para> <para> One engine per module directory for the life of the process: a re-import (<c>Import-Module -Force</c>, <c>Remove-Module</c> + <c>Import-Module</c>) reuses it, the same way assemblies loaded into the default context used to survive a re-import, and two installed versions of the module imported side by side each get their own. </para> <para> This assembly is deliberately named after the module rather than shared with other modules: one shared loader in the default context would be the very "first one wins" problem it solves. </para> </summary> </member> <member name="F:PSDataRepository.Loader.ModuleEngine.CommandsAssemblyName"> <summary>Name of the binary module assembly PowerShell imports.</summary> </member> <member name="M:PSDataRepository.Loader.ModuleEngine.LoadCommands(System.String)"> <summary> Loads the binary module assembly from <paramref name="moduleDirectory"/> (<c>{ModuleRoot}/bin/{TFM}</c>) into that directory's engine context, creating the context on first use. The result is what <c>Import-Module -Assembly</c> takes. </summary> </member> <member name="M:PSDataRepository.Loader.ModuleEngine.VerifySignedLikeLoader(System.String)"> <summary> Refuses a binary module that is not signed with the loader's own strong-name key, checked from metadata before any of its code can run. The extension loader inside the engine anchors its trust policy on the same key; this extends that anchor to the engine entry point, so a replaced <c>PSDataRepository.Commands.dll</c> fails the import instead of running. An unsigned loader (a build without the key) skips the check; the extension loader then refuses every extension on its own side. </summary> </member> </members> </doc> |