Bug 33728 - Assembly.Load loads the same assembly if multiple assemblies have the same name.
Summary: Assembly.Load loads the same assembly if multiple assemblies have the same name.
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: General (show other bugs)
Version: 4.0.0
Hardware: PC All
: --- normal
Target Milestone: ---
Assignee: Aleksey Kliger
URL:
Depends on:
Blocks:
 
Reported: 2015-09-06 17:16 UTC by cyral
Modified: 2018-04-25 21:32 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Solution demonstrating the issue. Make sure to build Plugin 1 and Plugin 2 before running Plugin Tester. Running on Microsoft's .NET and Mono will produce different results. (203.50 KB, application/x-gzip)
2015-09-06 17:16 UTC, cyral
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description cyral 2015-09-06 17:16:04 UTC
Created attachment 12798 [details]
Solution demonstrating the issue. Make sure to build Plugin 1 and Plugin 2 before running Plugin Tester. Running on Microsoft's .NET and Mono will produce different results.

Using Assembly.Load to load assemblies that have the same assembly name (not file name) will cause the same assembly to be loaded (the first one.)

For example, a plugin system could have the following assemblies:

1. /plugins/Test Plugin/plugin.dll
2. /plugins/Another Plugin/plugin.dll

If each .dll has the same assembly name, each call to Assembly.Load will return the first assembly.

Running on Mono, the results of running the "Plugin Tester" program will result in:

---
Path: W:\Programming\C#\AssemblyLoadTest\Plugin Tester\bin\Debug\plugins\1\plugin.dll
Plugin #1 loaded.
Path: W:\Programming\C#\AssemblyLoadTest\Plugin Tester\bin\Debug\plugins\2\plugin.dll
Plugin #1 loaded.

Test results: 2 plugins loaded.
Duplicated Assembly: plugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null HashCode: 443309356
Duplicated Assembly: plugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null HashCode: 443309356
---

Even though two different assemblies (with different bytes) were passed to Assembly.Load, the same assemblies were returned.

The expected result, running on .NET is:

---
Path: W:\Programming\C#\AssemblyLoadTest\Plugin Tester\bin\Debug\plugins\1\plugin.dll
Plugin #1 loaded.
Path: W:\Programming\C#\AssemblyLoadTest\Plugin Tester\bin\Debug\plugins\2\plugin.dll
Plugin #2 loaded.

Test results: 2 plugins loaded.
plugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null HashCode: 12036987
plugin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null HashCode: 42715336
---

You can see that each plugin was loaded and printed their output.

Attached is a solution that demonstrates the issue.

Renaming the assembly name of one of the plugins (through the project settings) will cause the correct behavior on mono.

It should be noted that in mono and .NET, Assembly.LoadFrom(file) will always return the first assembly in this case, however .Load(bytes) does not under .NET.
Comment 1 cyral 2015-10-17 14:31:54 UTC
It seems this is caused by Assembly.Load caching based on the assembly name. See #11199
Comment 2 Aleksey Kliger 2018-04-25 21:32:03 UTC
This should be fixed in mono master by https://github.com/mono/mono/commit/40c13f7b0ff71bfff8e58f8bd66bca0734d7d284