That cleared up this problem, thanks!
I had trouble initially connecting to my local SQL instance though. I
had TCP/IP enabled for the server, but due to Mono limitations [1],
the ".\INSTANCE" syntax doesn't seem to work ("No such host is
known"). Replacing that with "localhost\INSTANCE" works, but you'll
get, "An existing connection was forcibly closed by the remote host",
unless you first enable the service SQL Server Browser. I didn't find
this documented anywhere, and MS.NET does not require the server
browser to resolve instance names.
In any case, sqlmetal now times out. The --debug stacktrace doesn't
hint at anything. Any suggestions?
Sandro
[1] https://bugzilla.novell.com/show_bug.cgi?id=393904
On Sep 30, 4:49 pm, Jonathan Pryor <[email protected]> wrote:
> Fired up Windows; have a solution:
>
> Copy:
>
> http://www.jprl.com/tmp/System.Data.Linq.dll
>
> to:
>
> C:\PROGRA~1\MONO-2~1.7\lib\mono\2.0\
>
> Background:
>
> There are (at least) two copies of a framework assembly: the copy in the
> GAC (Mono: $prefix/lib/mono/gac/...) and a copy where the C# compiler
> can reference it (Mono: $prefix/lib/mono/VERSION).
>
> Since Windows doesn't (normally) support symbolic links, these are two
> separate files (while on Linux the latter is a symlink to the former).
>
> Furthermore, Mono's sqlmetal.exe is in $prefix/lib/mono/VERSION, and (as
> per normal assembly resolution rules) it loads the
> $prefix/lib/mono/VERSION version BEFORE it checks the GAC.
>
> Result: just updating the System.Data.Linq.dll in the GAC won't fix
> sqlmetal, as that's loading a different version.
>
> - 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.
