[Mono-bugs] [Bug 74192][Nor] New - Secondary AppDomain loaded assembly loses reference

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by andrewarnott@byu.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=74192

--- shadow/74192	2005-03-29 12:34:39.000000000 -0500
+++ shadow/74192.tmp.8099	2005-03-29 12:34:39.000000000 -0500
@@ -0,0 +1,97 @@
+Bug#: 74192
+Product: Mono: Runtime
+Version: 1.1
+OS: GNU/Linux [Other]
+OS Details: Gentoo kernel 2.6.10
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: remoting
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: AndrewArnott@byu.edu               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Secondary AppDomain loaded assembly loses reference
+
+Description of Problem:
+A secondary AppDomain is created, an assembly is loaded into it, and an
+interface implementation is instantiated.  Then although the reference to
+the interface instance is still valid, a NullReferenceException is thrown
+when used.
+
+
+Steps to reproduce the problem:
+1. Download (soon to be) attached file.
+2. Extract contents with "tar xvzf appdomainbug.tgz"
+3. Change directory to "appdomainbug"
+4. Run "make test"
+
+
+Actual Results:
+rm -f "./bin/BugTest.exe" 2> /dev/null
+rm -f "./bin/BugTest.exe.mdb" 2> /dev/null
+rm -f "./bin/plugins/plugin.dll" 2> /dev/null
+rm -f "./bin/plugins/plugin.dll.mdb" 2> /dev/null
+mkdir -p ./bin
+mcs -debug  -out:./bin/BugTest.exe BugTest.cs PluginFinder.cs IPlugin.cs
+mkdir -p ./bin/plugins
+mcs -debug  -r:./bin/BugTest.exe -target:library
+-out:./bin/plugins/plugin.dll plugin.cs
+rm -f ./bin/plugin.dll 2> /dev/null
+./bin/BugTest.exe
+Creating appdomain...
+Establishing AppDomain with ApplicationBase: /home/ala55/appdomainbug/bin
+and PrivateBinPath: /home/ala55/appdomainbug/bin/plugins
+Looking up assembly at /home/ala55/appdomainbug/bin/plugins/plugin.dll...
+Loading assembly and plugin...
+Looking for assembly with name: plugin, Culture=neutral
+Plugin loaded? True
+
+Unhandled Exception: System.NullReferenceException: Object reference not
+set to an instance of an object
+make: *** [test] Error 1
+
+
+Expected Results:
+When copying the build from Mono to a Windows machine and running from
+Microsoft .NET, these are the results:
+Creating appdomain...
+Establishing AppDomain with ApplicationBase: C:\temp\appdomainbug\bin\
+and PrivateBinPath: C:\temp\appdomainbug\bin\/plugins
+Looking up assembly at C:\temp\appdomainbug\bin\plugins/plugin.dll...
+Loading assembly and plugin...
+Looking for assembly with name: plugin, Version=0.0.0.0, Culture=neutral,
+Public
+KeyToken=null
+Plugin loaded? True
+Plugin name: some name
+Completed successfully.
+
+How often does this happen? 
+Every time.  (yay)
+
+Additional Information:
+I include a simplified test case of the bug I found when writing an app
+that is designed to search its bin/plugins folder for .dlls that implement
+its IPlugin interface.  Whether compiled using csc or mcs, the assemblies
+run just fine under MS.NET and crash under mono.  I have only run the mono
+runtime under Linux (not Windows) during these tests.
+
+The hosting app is in a /bin folder, and the plugins are in /bin/plugins. 
+Every plugin has a reference to an assembly that is only found in the /bin
+folder (the app's exe -- or dll in my REAL case).  The plugin is found, and
+loaded just fine.  But as soon as it is accessed (to call an accessor
+method), mono throws an UNCATCHABLE NullReferenceException.  So maybe there
+are TWO BUGS here: that NullRef. is thrown, and that it cannot be caught.
+
+Oddly, when I copy the bin/plugins/plugin.dll to bin/plugin.dll, everything
+works fine.  This of course is not an acceptable permanent workaround.
+
+One additional test: "make testbin" (described below)
+"make testbin" Is the same as "make test", except that before running the
+test, the plugin.dll file is copied from the bin/plugins folder to bin. 
+This mysteriously makes everything work under Mono.  This step is NOT
+needed in Microsoft.NET.