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 > >> } > >> } > >> > >> > >> > >> > >> > >> >
