ipmo fails to load personal module #776
Conversation
|
A module or a DLL? |
|
Ah its a PR (sorry on phone), can you describe what was happening? We can't do a catch all here, and there are other locations this logic exists. |
|
Doess thi API throw exception? |
|
I think we indeed Specifically want to catch a FileNotFoundException here, but nothing else, and we'll have to track down in the old repo the other place this happens. |
|
In my scenario, it was trying to load the Microsoft.PowerShell.PSReadLine.dll in my ~/.powershell/Modules/PSReadLine directory. From what I could trace, this call to PowerShellAssemblyLoadContext::LoadFrom() calls Assembly.Load("PSReadLine"), which somehow calls PowerShellAssemblyLoadContext::Load("PSReadLine"). It throws FileNotFoundException in there because it can't find ~/PowerShell/bin/PSReadLine.dll. At the very least, Load() throws FileNotFoundException or FileLoadException. There could be other exceptions thrown. |
|
I was actually more worried about the locking, but I didn't observe any problem. |
|
Yeah this code is tricky because we're trying to simultaneously support three flavors in a bunch of different scenarios. |
|
That's why I asked about the history (and how well it's tested). |
|
Recent history is available in the psl-monad repo. I'll take a look at this tomorrow. Unfortunately we don't have extensive module testing (yet) so this code was tested by the good old "is it working yet" approach to getting the not-yet-deprecated snapin system to actually load all of PowerShell's assemblies yet (via the CorePsSnapIn for SMA and system modules for the the rest), keeping in mind that in .NET Core scenario, all these assemblies are already in the TPA, and so we're just satisfying PowerShell's demands (and letting it do its cmdlets analysis). |
|
Can you post the path it was going to attempt to load PsReadLine from? It should be a local variable once you break in this function. |
|
I was a bit surprised to find this complicated code, and it just looked a bit strangely written. |
|
My module was "PSReadLine", and its manifest file lists a "nested" assembly as "Microsoft.PowerShell.PSreadLine.dll". If you look at ClrFacade::LoadAssembly(), you see that it first attempts to call ClrFacade.Load("PSReadLine"), and then ClrFacade.LoadFrom(thefullpath). I guess if you don't like catch-all, you can catch at least the 4 exceptions listed there? Anyway, ClrFacade ends up calling PsAssemblyLoadContext.Load(), which only looked for following: It then goes to LoadFrom(), which repeats the call to Load(), and fails identically as the first call. But since LoadFrom() did not have the catches, it gives up prematurely, and the DLL is never found/loaded. |
|
🎉This issue was addressed in #10017, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9954, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9885, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9875, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9862, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9854, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9843, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #9805, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #10364, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #10421, which has now been successfully released as Handy links: |
There are two ways to load a module, Load(Module), or LoadFrom(Path). Load(Module) only seems to look in default (bin) directory, so personal Modules (in $HOME/.powershell/Modules, e.g.) needs LoadFrom() to load it correctly.
But it seems that LoadFrom() calls Load() anyway, before attempting to load from path. But since Load() throws an exception if it cannot load, LoadFrom() never gets to try to load from path, resulting in an error.
We need to put try..catch around the Load() call, so that if it throws exception, it will still attempt to load from full path.
This change is