Resolve assemblies globally without locking #1735
Comments
ferventcoder
changed the title
ferventcoder
added a commit
that referenced
this issue
Feb 24, 2019
When dynamically loading assemblies, do not lock those assembly files on the file system. Instead of loading the assembly file directly, read the Assembly binary into memory and then load the result. As .NET will happily load an assembly multiple times, synchronize and ensure that if the assembly is already loaded, use that instead of attempting to load the assembly again.
ferventcoder
added a commit
to ferventcoder/choco
that referenced
this issue
Feb 24, 2019
* stable: (chocolateyGH-1738)(api) Change DI container verification (maint) add logging for Lets (maint) formatting (chocolateyGH-1735) Globally resolve assemblies w/out locking (maint) remove unused file (doc) update copyright year (doc) add VERIFICATION (maint) update copyright year (chocolateyGH-1734) Fix: Exit 1 if package throws an error
ferventcoder
added a commit
that referenced
this issue
Mar 15, 2019
Due to GH-1735, assemblies were being read into memory and then loaded, preventing locking from occurring. This also needed to resolve all currently loaded assemblies and use the ones that are already loaded if they are requested a second time. This ensured no issues with duplicate assembly loads. .NET already has the ability to detect duplicate assembly loads based on assembly location. It appears PowerShell's `Import-Module` uses the same loading rules when given an assembly location. When the location was already there, it would use the existing assembly. However having assemblies loaded up from memory would cause duplicate assembly loads. Fix the module imports for DLLs to look to see if the assembly name is already loaded into memory. If so, use that, otherwise use the old method for importing the module.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What You Are Seeing?
Assemblies that Chocolatey loads are being locked on the file system.
What is Expected?
To be able to upgrade those components without worrying if they are locked.
How Did You Get This To Happen? (Steps to Reproduce)
Installed a chocolatey-agent that takes a dependency on Chocolatey.
Run lockhunter to see the file locks while Chocolatey is executing (and possibly during the life of the application running Chocolatey assemblies).
The text was updated successfully, but these errors were encountered: