Fix a couple of issues involving assembly loading
authorKoundinya Veluri <kouvel@microsoft.com>
Tue, 10 Nov 2015 18:35:30 +0000 (10:35 -0800)
committerKoundinya Veluri <kouvel@microsoft.com>
Wed, 11 Nov 2015 19:43:28 +0000 (11:43 -0800)
commit6a617fbd6296352fa1041bdf5efe02da1a41b9a7
tree78a8b5a79f085abc1548667221ff252bb20c639a
parent077d5cb53bf9c0339cca6e2dc64e1d523987098d
Fix a couple of issues involving assembly loading

Fixes #1740
- After an assembly is loaded through a custom load context, when its dependencies are being loaded and the dependencies are in an app folder but not on the TPA list, don't search app paths when using the TPA binder, and instead use the default binder for the dependent assembly to load dependencies through the same custom AssemblyLoadContext.

Fixes #1187
- In the AssemblyName created by AssemblyLoadContext.GetAssemblyName(), don't initialize the CodeBase property since it's not in the exposed surface area for .NET Core. If the AssemblyName is passed to Assembly.Load(), note that regardless of the path sent to GetAssemblyName(), default search orders are still used to load the assembly by name. A custom AssemblyLoadContext would need to be used to control where an assembly is loaded from.

- Fixed a couple of error messages that mentioned phone
src/binder/assemblybinder.cpp
src/binder/binderinterface.cpp
src/binder/clrprivbinderassemblyloadcontext.cpp
src/binder/clrprivbindercoreclr.cpp
src/binder/inc/assemblybinder.hpp
src/binder/inc/clrprivbindercoreclr.h
src/mscorlib/src/mscorlib.txt
src/vm/assemblyname.cpp