Thank you a lot!
- Alexey.
Nicko Cadell wrote:
Alexey,
I will add your enhancement. I think that the risk can be mitigated by
education (i.e. documenting that an assembly qualified type name is
preferred, especially for production environments) and also by attempting to
lookup the type in the relativeAssembly assembly first (as you have done). I
will also add an internal log message to indicate which assembly the type
was loaded from.
Nicko
-----Original Message-----
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
Sent: 22 February 2004 23:25
To: Log4NET Dev
Subject: Re: [Fwd: Re: There seems an easy fix for loading
custom classes. What do you think?]
It is an unnecessary hassle to require full assembly names
in a logger configuration file. At least it would require us
to change those files for every build.
Unless there is a special security requirement, I do not
think the code makes the situation worse. Default behaviour
is preserved and additional behaviour is introduced when
default behaviour does not work.
If you still believe it is too risky, could you please add a
callback interface, so the behaviour could be controlled from outside?
- Alexey.
Nicko Cadell wrote:
Alexey,
I'm not sure what issue you are having with loading custom
classes that
requires this change?
I would not call this a 'fix' because loading custom classes
works fine
if you specify an assembly qualified type name. This could be an
enhancement that means you don't need to specify the fully
qualified type name.
When a type name is specified that is not assembly qualified
we could
add this code to look in all the loaded assemblies for a
type with that name.
Consider the following questions:
Does this impose additional security requirements? i.e. do
we need more
privileges to call AppDomain.CurrentDomain.GetAssemblies()
than to call
Assembly.GetType()? Especially when the assembly being
reflected is the
calling assembly.
Does this code introduce non-deterministic type binding? What if the
same type exists in more than one of the loaded assemblies? Does
AppDomain.CurrentDomain.GetAssemblies() always return the
assemblies in
the same order? Is this a security weakness? Could an attacker add a
new assembly that substitute a different custom class?
(probably not with CAS).
Will the custom class be loaded into the AppDomain when log4net is
configured? It is best practice to configure log4net as early as
possible in the process execution. Additional assemblies will not be
loaded into the AppDomain until a Type from the assembly is
referenced,
therefore they probably will not have been loaded at the
time log4net
is configured, also this is a JIT implementation detail that
may change
unpredictably in future versions of the runtime.
Cheers,
Nicko
-----Original Message-----
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
Sent: 20 February 2004 21:26
To: [email protected]
Subject: [Fwd: Re: There seems an easy fix for loading
custom classes.
What do you think?]
I should have sent it to a dev list.
- Alexey.
-------- Original Message --------
Subject: Re: There seems an easy fix for loading custom
classes. What do you think?
Date: Fri, 20 Feb 2004 10:33:34 -0800
From: Alexey N. Solofnenko <[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]>
Reply-To: Log4NET User <[email protected]>
<mailto:[email protected]>
To: Log4NET User <[email protected]>
<mailto:[email protected]>
References: <[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]>
Sorry, the additional code should pass "false" instead of
throwOnError.
Type type=relativeAssembly.GetType(typeName, false,
ignoreCase);
if (type!=null) return type;
foreach (Assembly assembly in
AppDomain.CurrentDomain.GetAssemblies()) {
type=assembly.GetType(typeName, false, ignoreCase);
if (type!=null) return type;
}
if (throwOnError) throw new TypeLoadException("Type
'"+typeName+"' cannot be found");
else return null;
- Alexey.
Alexey N. Solofnenko wrote:
Hello,
I have tried the following code in
SystemInfo.getTypeFromString() and it works well on my computer.
Instead of looking for a class in just relativeAssembly, all loaded
assemblies are searched for the class. Do you think log4net can be
updated to do the same?
Sincerely,
Alexey Solofnenko.
public static Type GetTypeFromString(Assembly
relativeAssembly, string typeName, bool throwOnError, bool
ignoreCase)
{
// Check if the type name specifies the
assembly name
if(typeName.IndexOf(',') == -1)
{
//LogLog.Debug("SystemInfo: Loading type
["+typeName+"] from assembly ["+relativeAssembly.FullName+"]");
#if NETCF
return
relativeAssembly.GetType(typeName, throwOnError);
#else
Type
type=relativeAssembly.GetType(typeName, throwOnError, ignoreCase);
if (type!=null) return type;
foreach (Assembly assembly in
AppDomain.CurrentDomain.GetAssemblies()) {
type=assembly.GetType(typeName, false, ignoreCase);
if (type!=null) return type;
}
if (throwOnError) throw new
TypeLoadException("Type '"+typeName+"' cannot be found");
else return null;
#endif
}
else
{
// Includes assembly name
//LogLog.Debug("SystemInfo: Loading type
["+typeName+"] from global Type");
#if NETCF
return Type.GetType(typeName, throwOnError);
#else
return Type.GetType(typeName, throwOnError,
ignoreCase);
#endif
}
}
