[Mono-bugs] [Bug 42100][Nor] New - AppDomain.CurrentDomain.FriendlyName return invalid domain name

[bugzilla-daemon@rocky.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 gfr@skynet.be.

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

--- shadow/42100	Tue Apr 29 13:30:01 2003
+++ shadow/42100.tmp.20196	Tue Apr 29 13:30:01 2003
@@ -0,0 +1,97 @@
+Bug#: 42100
+Product: Mono/Runtime
+Version: unspecified
+OS: Red Hat 8.0
+OS Details: Red Hat 9 with mono/mcs taken from cvs at April 29, 2003
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: gfr@skynet.be               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Summary: AppDomain.CurrentDomain.FriendlyName return invalid domain name
+
+Description of Problem:
+
+This problems could produce some portability issue. When
+a dotnet application is launched under mono run-time, it give 
+it's name as Friendly Name of the application. Under the 
+microsoft run-time the behaviour is completely different. 
+
+The MSDN Site give the following remark about the AppDomain.FriendlyName:
+
+  The friendly name of the default application domain is the name 
+  of the assembly file loaded in the application domain. The friendly
+  name is formed by stripping the directory specification from the
+  assembly's codebase. 
+
+  For example, if an assembly with the file  name 
+  "c:\MyAppDirectory\MyAssembly.exe" is loaded in the default 
+  application domain, the friendly name of that application
+  domain is "MyAssembly.exe".
+
+This remark was taken from the http://msdn.microsoft.com/library/en-
+us/cpref/html/frlrfsystemappdomainclassfriendlynametopic.asp
+
+I don't know if they exist any other method to get the name of the
+application started. May be do you know another one to retreive it.
+
+Steps to reproduce the problem:
+1. Create a file called sample.cs with the following content
+
+>>> SOT >>>
+namespace Test5
+{
+  public class Test5
+  {
+    static public void Main ()
+    {
+      System.Console.Out.WriteLine 
+("System.AppDomain.CurrentDomain.FriendlyName  = {0}", 
+        System.AppDomain.CurrentDomain.FriendlyName);
+    }
+  }
+}
+>>> EOT >>> 
+
+2. build the console application with this command :
+  
+  mcs -target:exe -out:sample.exe sample.cs
+
+3. run the application with the following command :
+
+  mono sample.exe
+
+Actual Results:
+
+  System.AppDomain.CurrentDomain.FriendlyName  = mono
+
+Expected Results:
+
+  System.AppDomain.CurrentDomain.FriendlyName  = sample.exe
+
+How often does this happen? 
+
+  Each time
+
+Additional Information:
+
+  The bug are not a blocking one. But in the case of a console
+  application it could be pity to see something like 
+
+    mono [option] ...
+
+  when we run the command ./MyApp.exe --help
+
+
+  This case could occurs on any linux system on which the magic 
+  code of the .exe has been registered to the binfmt_misc
+  kernel's functionnality.
+
+Best Regards,
+Thanks for your help
+Gilles