sqlmetal shipped with Mono 2.6.7
Sandro
shipped with mono 2.6.7 fails with:
Could not load dbLinqSchemaLoaderType type
'DbLinq.SqlServer.SqlServerSchemaLoader, System.Data.Linq,
Version=3.5.0.0, Culture=neutral [...]. Try using the --with-schema-
loader=TYPE option.
Any thoughts? sqlmetal is not listed as a Mono tool in the Novell
bugzilla, so I'm not sure where I should report this.
Sandro
Jonathan Pryor
> I'm not sure if this is the proper forum for this, but the sqlmetal
> shipped with mono 2.6.7 fails with:
Given that bugzilla.novell.com doesn't really have any appropriate
categories, this is currently it. I'll need to look into adding
appropriate bugzilla support.
> Could not load dbLinqSchemaLoaderType type
> 'DbLinq.SqlServer.SqlServerSchemaLoader, System.Data.Linq,
> Version=3.5.0.0, Culture=neutral [...]. Try using the --with-schema-
> loader=TYPE option.
So apparently I was an idiot when I was merging DbLinq and mono, as I
included SqlServerSchemaLoader in the trunk build but not the mono-2-6
build. Doh!
I just fixed this:
http://github.com/mono/mono/commit/7fa99d845fe8024ccb91580d554c66e1d7a5d448
So it should appear in Mono 2.6.8, but that doesn't really help you
now...
For now, you can download a just-built System.Data.Linq.dll which
contains the needed support from:
http://www.jprl.com/tmp/System.Data.Linq.dll
http://www.jprl.com/tmp/System.Data.Linq.dll.mdb
Just overwrite the current files in
e.g. /usr/lib/mono/gac/System.Data.Linq/3.5.0.0__b77a5c561934e089
(change the prefix as appropriate) with the files above, and sqlmetal
should work for you.
Sorry for the inconvenience.
- Jon
Sandro
I'm still getting the error. Probably should mention I'm running
Windows. I replaced the dlls in [1] with the ones you linked to. Is
there another step I'm missing?
Sandro
[1] C:\Program Files\Mono-2.6.7\lib\mono\gac\System.Data.Linq
\3.5.0.0__b77a5c561934e089
Jonathan Pryor
> Finally got around to trying this again with your updated dlls, but
> I'm still getting the error. Probably should mention I'm running
> Windows.
Just as a basic sanity measure, are you sure you're running your app via
Mono and not .NET? I don't have the Windows install around to quickly
test on, but if you just use 'sqlmetal.exe' at the command line you'll
be using the .NET runtime, which will then attempt to load .NET's
System.Data.Linq.dll, which will fail to find any DbLinq types (for
~obvious reasons). You'll need to ensure that 'mono sqlmetal.exe' is
being used when using Mono's sqlmetal.exe.
(I suppose a sqlmetal.bat might be shipped to ensure that mono is being
used, but iirc .exe files are preferred to .bat files, so 'sqlmetal'
will load sqlmetal.exe, not sqlmetal.bat...)
- Jon
Sandro
%. .NET 3.5 and its tools are not in the default path. I then type:
C:\...> sqlmetal -?
DbLinq Database mapping generator 2008 version 0.20
for Microsoft (R) .NET Framework version 3.5
Distributed under the MIT licence (http://linq.to/db/license)
sqlmetal [OPTIONS] [<DBML INPUT FILE>]
Generates code and mapping for DbLinq. SqlMetal can:
- Generate source code and mapping attributes or a mapping file from
a database.
- Generate an intermediate dbml file for customization from the
database.
- Generate code and mapping attributes or mapping file from a dbml
file.
[...]
C:\...> sqlmetal --server=.\SA --database=FOO --namespace=Foo.DB --
code=Foo.DB.cs
DbLinq Database mapping generator 2008 version 0.20
for Microsoft (R) .NET Framework version 3.5
Distributed under the MIT licence (http://linq.to/db/license)
sqlmetal: Could not load dbLinqSchemaLoaderType type
'DbLinq.SqlServer.SqlServerSchemaLoader, System.Data.Linq,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Try using the --with-schema-loader=TYPE option.
I disassembled the System.Data.Linq.dll you provided and I see the
DbLinq.SqlServer classes there, but I guess it can't find them for
some reason. Do I need to rebuild or clear some sort of gac cache or
something?
Sandro
Jonathan Pryor
> I start a Mono command prompt, which adds the mono bin folder to %PATH
> %. .NET 3.5 and its tools are not in the default path. I then type:
%PATH% is irrelevant. All that matters is which runtime is used to load
sqlmetal.exe, and if 'sqlmetal.exe' is in your path, then .NET will be
used to execute it when you just use 'sqlmetal' and/or 'sqlmetal.exe'.
(IIRC, .bat in the path won't help, as the .exe has precedence over
the .bat unless you run 'sqlmetal.bat', and I don't know if a .bat
or .cmd is present anyway...)
Thus, you'd either need to completely uninstall .NET (;-) or make sure
you use mono by running 'mono path\to\mono\sqlmetal.exe'.
Or perhaps running 'sqlmetal.cmd' (assuming it exists...).
Alternatively, download the DbLinq binary package and use DbMetal.exe.
You can run DbMetal-generated output under Mono by compiling with the
MONO_STRICT #define.
- Jon
Sandro
paths. I thought I had mentioned that, but I don't see it in the
thread. My last post was intended to demonstrate that the correct
sqlmetal was called by the batch script, so address your point about
precedence of .exe/.bat and which sqlmetal was being called:
C:\...> mono "C:\PROGRA~1\MONO-2~1.7\lib\mono\2.0\sqlmetal.exe" --
code=Foo.DB.cs
DbLinq Database mapping generator 2008 version 0.20
for Microsoft (R) .NET Framework version 3.5
Distributed under the MIT licence (http://linq.to/db/license)
sqlmetal: Could not load dbLinqSchemaLoaderType type
'DbLinq.SqlServer.SqlServerSchemaLoader, System.Data.Linq,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
Try using the --with-schema-loader=TYPE option.
Jonathan Pryor
Sandro
suggestions you already gave me, and I already have those updated
dlls.
I'll try using DBLinq itself at some point for my project, but your
updated dlls don't seem to be working in Mono, so any upcoming 2.6.8
release still won't work on Windows.
Sandro
Jonathan Pryor
> That's just a link back to this thread. My post was a follow-up to the
> suggestions you already gave me, and I already have those updated
> dlls.
I didn't know you were trying the updated DLLs. I somehow missed that.
Are you sure you're replacing the System.Data.Linq.dll assembly that's
in Mono's GAC? That should work, as
monodis --typedef System.Data.Linq.dll
shows that the type DbLinq.SqlServer.SqlServerSchemaLoader is present
within that assembly (unlike the 2.6.7 System.Data.Linq.dll), so it
should work. If it doesn't, either it's some other error, or you're not
replacing the assembly within Mono's GAC.
- Jon
Sandro
so I figure you would have mentioned then whether that was incorrect.
I also mentioned [2] that I disassembled the new dlls you provided and
the class was there, but the error still occurs, so something else is
wrong.
I asked whether there was some sort of cache I needed to generate, but
you didn't mention anything in response to that question, so I presume
not. I don't know what else it could be.
Sorry I'm sometimes a little delayed in my replies, I only have time
to work on this in fits and spurts, so you've probably forgotten that
I started this whole thread; I figured you might be thinking I'm
someone new with the same problem. :-)
Sandro
[1] http://groups.google.com/group/dblinq/msg/0fcf5ec77f4a6c0e
[2] http://groups.google.com/group/dblinq/msg/fd8b7afee414abb9
Jonathan Pryor
Windows' lack of symbolic links sucks. :-)
Specifically, on Unix, there are two sets of assemblies:
$prefix/lib/mono/gac/System.Data.Linq/VERSION/System.Data.Linq.dll
$prefix/lib/mono/2.0/System.Data.Linq.dll
The latter is a symlink to the former. [0]
Since Windows doesn't (normally) have symbolic links, thus those are two
separate files.
Worse, sqlmetal.exe is in...$prefix/lib/mono/2.0, and thus by the normal
assembly resolution rules, it loads the *copy* in $prefix/lib/mono/2.0
rather than using the GAC version.
Thus, the fix is simple: Copy
http://www.jprl.com/tmp/System.Data.Linq.dll
to
C:\PROGRA~1\MONO-2~1.7\lib\mono\2.0\
Things should work for you then. (At least, I no longer get the "Could
not load dbLinqSchemaLoaderType..." message anymore.)
- Jon
[0] This is actually not much different from .NET, where the GAC has one
copy of the assembly, and %WINDIR%\Microsoft.NET\Framework\... has
another copy. Then C:\Program Files*\...\Reference Assemblies\ has yet
another. There may be a fourth copy somewhere else.
Remember: the C# compiler does NOT look for assemblies in the GAC.
Jonathan Pryor
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
On Wed, 2010-09-29 at 14:38 -0700, Sandro wrote:
Sandro
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
Jonathan Pryor
> In any case, sqlmetal now times out. The --debug stacktrace doesn't
> hint at anything. Any suggestions?
All I can suggest is two things:
1. Use -c "CONNECTION_STRING" instead of /user, /password, etc.
2. You may need to configure SQL Server to allow access. Here's the
handy dandy "omfg that's gigantically long are you kidding me"
tutorial I wrote for getting a Mono-hosted NerdDinner app to
connect to a Windows-hosted SQL Server instance:
Hopefully that's not entirely obsolete...
I imagine you'll need (5)(C), (5)(D), and (5)(E).
- Jon
Sandro
exact same connection string, just modified to name localhost
explicitly as mentioned earlier. I've already enabled TCP/IP and
restarted the SQL instance. I also tried the firewall mods even though
this is a purely local operation.
Mono seems to connect to the instance, but it times out after exactly
30 seconds when executing a command (presumably when fetching the
schema or something). I've even granted the user I'm connecting with
complete access to the db, ie. granted all server roles and all
permissions to the specific database to connect to, thinking it was
perhaps a permission issue, to no avail:
DbLinq Database mapping generator 2008 version 0.20
for Microsoft (R) .NET Framework version 3.5
Distributed under the MIT licence (http://linq.to/db/license)
sqlmetal: System.Data.SqlClient.SqlException: Timeout expired. The
timeout period elapsed prior to completion of the operation or the
server is not responding. --->
Mono.Data.Tds.Protocol.TdsTimeoutException: Timeout expired. The
timeout period elapsed prior to completion of the operation or the
server is not responding.
at Mono.Data.Tds.Protocol.Tds.CheckForData (Int32 timeout) [0x00000]
in <filename unknown>:0
at Mono.Data.Tds.Protocol.Tds.ExecuteQuery (System.String sql, Int32
timeout, Boolean wantResults) [0x00000] in <filename unknown>:0
at Mono.Data.Tds.Protocol.Tds80.Execute (System.String commandText,
Mono.Data.Tds.TdsMetaParameterCollection parameters, Int32 timeout,
Boolean wantResults) [0x00000] in <filename unknown>:0
at System.Data.SqlClient.SqlCommand.Execute (Boolean wantResults)
[0x00000] in <filename unknown>:0
--- End of inner exception stack trace ---
at System.Data.SqlClient.SqlCommand.Execute (Boolean wantResults)
[0x00000] in <filename unknown>:0
at System.Data.SqlClient.SqlCommand.ExecuteReader (CommandBehavior
behavior) [0x00000] in <filename unknown>:0
I'll try the newest DbLinq the next time I have a chance, unless you
have some other suggestion. Thanks for all the help.
Sandro
On Oct 4, 2:54 pm, Jonathan Pryor <jonpr...@vt.edu> wrote:
> All I can suggest is two things:
>
> 1. Use -c "CONNECTION_STRING" instead of /user, /password, etc.
> 2. You may need to configure SQL Server to allow access. Here's the
> handy dandy "omfg that's gigantically long are you kidding me"
> tutorial I wrote for getting a Mono-hosted NerdDinner app to
> connect to a Windows-hosted SQL Server instance:
>