Load assembly from module base path before trying to load from GAC #8073
Conversation
|
@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? |
|
@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!
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!
|
@daxian-dbw Please have another look. |
|
@SteveL-MSFT @adityapatwardhan Here is example scenario: servicing a multi-version module. @adityapatwardhan is there an issue for this PR? did somebody complain? |
|
@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. |
|
@SteveL-MSFT That's a valid scenario. |
|
@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. |
adityapatwardhan
force-pushed
the
LoadAssembly
branch
from
92e7523 to
87b7d0b
Compare
adityapatwardhan
requested review from
Francisco-Gamino,
HemantMahawar,
JamesWTruher,
anmenaga,
joeyaiello and
mirichmo
as code owners
adityapatwardhan
force-pushed
the
LoadAssembly
branch
from
87b7d0b to
f07d477
Compare
|
@TravisEz13 Assigning this to you as I would like to get this in the next release. |
6 participants
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