Checking the assertion is...difficult.
The problem is that SchemaLoaderFactory.Load(Provider,string,string) is
the main entry point, converting the strings into Types:
public ISchemaLoader Load(Parameters parameters, string
dbLinqSchemaLoaderTypeName, string databaseConnectionTypeName)
{
AppDomain.CurrentDomain.AssemblyResolve +=
CurrentDomain_AssemblyResolve;
Type dbLinqSchemaLoaderType =
Type.GetType(dbLinqSchemaLoaderTypeName);
Type databaseConnectionType =
Type.GetType(databaseConnectionTypeName);
if (dbLinqSchemaLoaderType == null)
throw new ArgumentException("Unable to resolve
dbLinqSchemaLoaderType: " + dbLinqSchemaLoaderTypeName);
if (databaseConnectionType == null)
throw new ArgumentException("Unable to resolve
databaseConnectionType: " + databaseConnectionTypeName);
ISchemaLoader loader = Load(parameters, dbLinqSchemaLoaderType,
databaseConnectionType);
AppDomain.CurrentDomain.AssemblyResolve -=
CurrentDomain_AssemblyResolve;
return loader;
}
So ~every time you use 'DbMetal.exe /provider:...', you'll hit this
codepath. (Whether CurrentDomain_AssemblyResolve() is used is a more
difficult matter, as it depends on whether Type.GetType() fails in
looking for the assembly in the default search locations.)
Furthermore, if you don't have one of the DB providers installed, e.g.
you're missing FirebirdSql.Data.FirebirdClient.dll, and use
you /provider:Firebird, then Type.GetType() won't find the type, and
CurrentDomain_AssemblyResolve() will be used...which will search the
current working directory (again, wtf?!), then trawl the GAC (which is
usually a bad idea, particularly since it uses the latest version of any
assembly it finds, which won't necessarily be the right one).
If anything, System.Reflection.Assembly.LoadWithPartialName() should be
used instead of manually trawling the GAC. (Though
Assembly.LoadWithPartialName() is [Deprecated], precisely because it's a
bad idea...)
So, given that in all likelihood this code path is being hit...and in
all likelihood not doing anything of consequence (seriously, the current
working directory?!)...I'm inclined to remove it, just for sanity's
sake.
- Jon
On Fri, 2009-05-01 at 07:28 +0200, Pascal Craponne wrote:
> Well, you should check my assertion first :)
>
>
> On Fri, May 1, 2009 at 03:02, Jonathan Pryor <[email protected]> wrote:
>
> So should we remove the code then? If so, the attached patch
> should do it.
>
> Thanks,
>
> - Jon
>
>
>
>
> On Thu, 2009-04-30 at 22:19 +0200, Pascal Craponne wrote:
>
> > It is never used, if I remember well.
> >
> > On Thu, Apr 30, 2009 at 22:13, Jonathan Pryor
> > <[email protected]> wrote:
> >
> > For mostly unrelated reasons (due to a bad
> > configuration), I found myself digging through
> >
> src/DbMetal/Generator/Implementation/SchemaLoaderFactory.cs, specifically
> > SchemaLoaderFactory.CurrentDomain_AssemblyResolve(),
> > and found myself wondering...what's going on?
> >
> > Specifically, it appears to contain code which will
> > probe the current working directory for assemblies
> > that couldn't be found. Thus, the questions:
> >
> > 1. Is this really necessary?
> >
> > 2. The current working directory? Seriously? Keep
> > in mind that DbMetal.exe is a command-line app;
> > thus, with the current logic it'll probe whatever
> > directory you happen to be in when running the app.
> > This seems decidedly counter-intuitive, as merely
> > changing your directory will either fix or cause
> > problems.
> >
> > It would seem more rational to probe DbMetal.exe's
> > directory...but that's what Type.GetType() already
> > does.
> >
> > 3. It assumes where the GAC is -- %SystemRoot%
> > \Assembly\GAC, etc. Aside from the obvious that
> > this won't work on Mono, this relies on an
> > implementation detail of .NET which could change at
> > any time.
> >
> > For the Mono case, the "workaround" is to just never
> > hit that code path in the first place (i.e. provide
> > a correct fully qualified type name), so this isn't
> > a major problem. It's just a "wtf?!" moment,
> > something I'd prefer to have fewer of...
> >
> > Thanks,
> > - Jon
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---
