Load assembly from module base path before trying to load from GAC - #8073
Conversation
|
Steve Lee (@SteveL-MSFT) I guess this would technically be a breaking change if someone had a assembly with the same name in the module base folder and are relying on loading it from GAC instead. But, I believe that should be a very rare occurance. Your thoughts? |
|
Aditya Patwardhan (@adityapatwardhan) I can't imagine a scenario where a module author has an assembly in their module base folder but expects the assembly from the GAC to be loaded |
|
Technically it's breaking, let's document it as breaking, but I don't think this needs committee review |
There was a problem hiding this comment.
If we already got the resolved assembly path, we can skip the loading, right? The loading is solely for getting the path of the assembly. When the target assembly is in GAC, we have to load it in order to get the path, but not if we already resolved the assembly file path.
There was a problem hiding this comment.
In this case, we actually want to load from module base first. In the Resolve method, we do not have access to module base so we need to do this here. If there are alternatives, please suggest.
There was a problem hiding this comment.
Please add a comment to the code so it is clear to other developers that we really want to load the assembly here, not just return the pathname. Thanks!
Paul Higinbotham (PaulHigin)
left a comment
There was a problem hiding this comment.
LGTM
There was a problem hiding this comment.
Please add a comment to the code so it is clear to other developers that we really want to load the assembly here, not just return the pathname. Thanks!
|
Dongbo Wang (@daxian-dbw) Please have another look. |
|
Steve Lee (@SteveL-MSFT) Aditya Patwardhan (@adityapatwardhan) Here is example scenario: servicing a multi-version module. Aditya Patwardhan (@adityapatwardhan) is there an issue for this PR? did somebody complain? |
|
Andrew (@anmenaga) the real world scenario is that we have Windows partners that also ship their modules on PSGallery. The PSGallery version that the user explicitly installed may be newer than the one that is inbox. Currently, importing the module loads the older assembly in the GAC which doesn't match the updated module. |
|
Steve Lee (@SteveL-MSFT) That's a valid scenario. |
|
Andrew (@anmenaga) The updated one in the GAC may not be compatible with modules that were tested against a specific version. I think this is the tradeoff of app-local versions of assemblies. At this time, I don't think we should solve this problem universally. |
92e7523 to
87b7d0b
Compare
87b7d0b to
f07d477
Compare
|
Travis Plunk (@TravisEz13) Assigning this to you as I would like to get this in the next release. |
…owerShell#8073) [Breaking Change] When a binary module has the module assembly in GAC, we load the assembly from GAC before trying to load it from module base path. This change attempts to load it from module base path before looking up in GAC.
PR Summary
When a binary module has the module assembly in GAC, we load the assembly from GAC before trying to load it from module base path.
This change attempts to load it from module base path before looking up in GAC.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests