DbMetal on Mono "SystemRoot" Env. Var

[Zak]

Running DbMetal, after copying DbMetal.exe.config to /build (easily
fixed with MonoDevelop),. I ran into some interesting exceptions.
Debugging led me to the following from Generator/Implementation/
SchemaLoaderFactory.cs:206-207

var systemRoot = Environment.GetEnvironmentVariable("SystemRoot");
string assemblyDirectory = Path.Combine(systemRoot, "Assembly");

"SystemRoot" returns null, since I do not have this set, throws
unhandled exception still not too big of a deal, but it should
probably output some sort of error instead. However, this further
raises the question of why traversing the GAC is even necessary. Any
points in the right direction would be great.

Hopefully I can help in some manner,

Zak

Backgound Info: I have been using .18 for a while now (thank you for
the work), but I would run DbMetal on a windows box. I found that
DbMetal was supposed to work on linux now and decided to start working
from svn yesterday.

[Pascal Craponne]

Hi Zak,

once upon a long ago, the dirty GAC parsing was implemented to make DbMetal look there when searching for drivers.

Anyway this is probably not necessary anymore (I think we had a talk about this with jon pryor) and should be removed.

Pascal.

--

You received this message because you are subscribed to the Google Groups "DbLinq" group.
To post to this group, send email to dbl...@googlegroups.com.
To unsubscribe from this group, send email to dblinq+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dblinq?hl=en.

[Jonathan Pryor]

On Wed, 2009-12-02 at 07:26 -0800, Zak wrote:
> Running DbMetal, after copying DbMetal.exe.config to /build (easily
> fixed with MonoDevelop),. I ran into some interesting exceptions.

What exceptions are you seeing?

> Debugging led me to the following from Generator/Implementation/
> SchemaLoaderFactory.cs:206-207

Yes, that code is ugly (and likely should be removed), but I don't see
how it could cause an exception under Linux. GacLoadAssembly() will see
that the directory doesn't exist and bail, causing
CurrentDomain_AssemblyResolve() to return null, which will cause
Type.GetType() to throw an exception (as the type couldn't be found).

So the proper solution is to insert a catch{} in the appropriate spot so
that a stack trace isn't printed (which may already happen), for
starters.

- Jon

[Zak]

On Dec 2, 3:14 pm, Jonathan Pryor <jonpr...@vt.edu> wrote:
> On Wed, 2009-12-02 at 07:26 -0800, Zak wrote:
> > Running DbMetal,  after copying DbMetal.exe.config to /build (easily
> > fixed with MonoDevelop),. I ran into some interesting exceptions.
>
> What exceptions are you seeing?

System.ArgumentNullException: Argument cannot be null.

because the environment variable did not exist, and calling
Environment.GetEnvironmentVariable("SystemRoot") returned null.

> So the proper solution is to insert a catch{} in the appropriate spot so
> that a stack trace isn't printed (which may already happen), for
> starters.

Handling or swallowing the exception would work too, but for now its
just commented out, and I was able to move forward. A few small
changes:

Index: DbLinq/Vendor/Implementation/SchemaLoader.TypeMapping.cs
===================================================================
--- DbLinq/Vendor/Implementation/SchemaLoader.TypeMapping.cs (revision
1285)
+++ DbLinq/Vendor/Implementation/SchemaLoader.TypeMapping.cs (working
copy)
@@ -187,6 +187,7 @@
case "datetime":
case "ingresdate":
case "timestamp":
+ case "timestamp with time zone": //PostgreSQL
case "timestamp without time zone":
case "time":
case "time without time zone": //reported by
twain_bu...@msn.com,
@@ -214,6 +215,7 @@
case "uuid":
return typeof(Guid);

+ case "array": // PostgreSQL has an array type, this is
just to get past it
case "void":
return null;

and I was able to get a .dbml which after editing (I am only after a
few tables in my db) generated code. I am however running into
problems with the generated code but that will be a different post
once I get more detail worked out.

Zak