[Mono-dev] [Fwd: [Mono-patches] r92329 -trunk/mcs/class/System.Web/System.Web.Util]

[Atsushi Eno]

Hey Kosta,

Well, I should have exactly indicated what I saw problematic.
It is not about why you guys introduced TARGET_DOTNET (I guessed it
is for such necessary case to differentiate .NET and mono runtimes),
but about why you guys needed to avoid
RuntimeEnvironment.SystemConfigurationFile in mono (!TARGET_DOTNET).

I agree that you'd need TARGET_DOTNET while am glad to hear that it
does not happen much.

Atsushi Eno


Konstantin Triger wrote:
> Hey Eno,
> 
> I did not completely understand your comment, but let me explain the background, so you will understand what Igor meant by this patch.
> 
> Usually we develop Web-related stuff in MS.Net environment, we take XSP, Sys.Web from mono trunk and all the rest from MS and run 'usual' console application. This perfectly works until there is something incorrect from MS.Net point of view. Fortunately this does not happen much, but when it does, we used TARGET_NET ifdef to differentiate. Thus, under TARGET_NET ifdef we put not always production ready, but MS.Net-correct code for development purposes only.
> 
> Can you please explain your point, what would you propose to put in ICalls.cs? If you see an option to combine paths, so the code will be common for mono.Net and MS.Net it would be great.
> 
> Regards,
> Konstantin Triger
> 
>> -----Original Message-----
>> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
>> bounces at lists.ximian.com] On Behalf Of Atsushi Eno
>> Sent: Monday, January 07, 2008 9:15 AM
>> To: mono-devel-list at lists.ximian.com
>> Subject: [Mono-dev] [Fwd: [Mono-patches] r92329 -
>> trunk/mcs/class/System.Web/System.Web.Util]
>>
>> Is there any reason to differentiate runtime environment shown like
>> this patch? I don't think we like such approach very much, especially
>> since our implementation of RuntimeEnvironment.SystemConfigurationFile
>> is implemented as:
>>
>> --------
>> public static string SystemConfigurationFile {
>> 	get {
>> 		// GetMachineConfigPath is internal and not protected by
>> CAS
>> 		string path = Environment.GetMachineConfigPath ();
>> 		if (SecurityManager.SecurityEnabled) {
>> 			new FileIOPermission
>> (FileIOPermissionAccess.PathDiscovery,
>> path).Demand ();
>> 		}
>> 		return path;
>> 	}
>> }
>> --------
>>
>> To me it looks that it just tries to skip security assertion.
>>
>> Atsushi Eno
>>
>>
>> -------- Original Message --------
>> Subject: [Mono-patches] r92329 -
>> trunk/mcs/class/System.Web/System.Web.Util
>> Date: Sun,  6 Jan 2008 03:14:55 -0500 (EST)
>> From: Igor Zalmanovich (igorz at mainsoft.com)
>> <mono-patches-list at lists.ximian.com>
>> To: mono-patches at lists.ximian.com, ximian.monolist at gmail.com,
>> mono-svn-patches-garchive-20758 at googlegroups.com
>>
>> Author: igorz
>> Date: 2008-01-06 03:14:55 -0500 (Sun, 06 Jan 2008)
>> New Revision: 92329
>>
>> Modified:
>>     trunk/mcs/class/System.Web/System.Web.Util/ICalls.cs
>> Log:
>> added #if TARGET_DOTNET
>>
>> Modified: trunk/mcs/class/System.Web/System.Web.Util/ICalls.cs
>> ===================================================================
>> --- trunk/mcs/class/System.Web/System.Web.Util/ICalls.cs	2008-01-06
>> 08:11:36 UTC (rev 92328)
>> +++ trunk/mcs/class/System.Web/System.Web.Util/ICalls.cs	2008-01-06
>> 08:14:55 UTC (rev 92329)
>> @@ -35,8 +35,14 @@
>>   	{
>>   		private ICalls () {}
>>
>> +#if TARGET_DOTNET
>> +		static public string GetMachineConfigPath () {
>> +			return
>> System.Runtime.InteropServices.RuntimeEnvironment.SystemConfigurationFi
>> le;
>> +		}
>> +#else
>>   		[MethodImplAttribute(MethodImplOptions.InternalCall)]
>>   		extern static public string GetMachineConfigPath ();
>> +#endif
>>
>>   		[MethodImplAttribute(MethodImplOptions.InternalCall)]
>>   		extern static public string GetMachineInstallDirectory ();
>>
>> _______________________________________________
>> Mono-patches maillist  -  Mono-patches at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-patches
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>