# Monday, May 25, 2009
Linq to sql comes with a really nice GUI to create those .dbml-files (which then will be used to create code). This works well for SQL Server Databases. Anyway - Linq to sql may also be used to access Sql Compact Edition but you can't use the GUI to drag-drop tables from an SQL-CE-Database onto the dbml-Editor. There are a lot of articles on the web which use SqlMetal to create that dbml-file which then can be used inside Visual Studios GUI. Also there seemed to be not only few people that wanted SqlMetal to skip some tables - this would be very useful when you often change something in your DB-
Schema but not want to drop every unused table every time again in the GUI or maybe if you want to rename some columns afterwards... So - recently I was in this situation and it was absolutely clear that there will be more of that work... so what I was looking for was a way to script that dbml-generation with support to exclude and rename tables and more (since we often deal with prefixes at our tables which I dont want inside my LinqClasses). After some research I figured out a way that works pretty nice for me. I wont go too much into details here because its too much..
First of all I used ildasm to disassemble SqlMetal into IL-Code via dump. Then I replaced most of the private words with public and added public here and there later when needed. Then I re-assembled that code using ilasm with the /DLL option. Finally I had a nice DLL where all that stuff I needed was no longer internal - it was all public - so I went on and created an own console-project which uses the SqlMetal.dll (the filename really MUST be SqlMetal.dll). I took the important parts of the old main method using .NET-Reflector and finally I had the pieces seperated where the the dbml-structure was extracted from an .sdf-file and where this structure was used to generate the .dbml-file. Nice. This structure is very simple to modify and the changes are copied to the dbml without any problems except if you change a name of a type and not change the type-reference in the association objects. Finally I did not want to write special code into this project everytime I have to deal with a new .sdf-file I decided to use the luainterface project to embed the lua-scripting language (very often used in games) to use lua-code for callbacks such as table exclusion, table and relation renaming, column renaming and whatever comes away... all I now have to do when it comes to dbml creation is to start my console
tool with a little lua-script as an argument and this (might) register some hooks where I may react to some columns by returning a different name. quite simple isn't it?? Oh well - some might be wondering how this stuff works - since sqlMetal is strong named... well since I will use this tool only in development I simply skipped the Strongname verification on my machine for that assembly by reflecting its strong name and using sn.exe to add the skipping rule like that
sn.exe -Vr *,<strongname-key>
I don't know if this is possible with earlier versions of sn.exe - I am using VS2008 SP1 by now.
So in the end I named the prog SqlCerium - since it is SqlMetal specialized for SQL CE and Ce is the chemical symbol for Cerium which is also a metal :-)

posted on Monday, May 25, 2009 11:07:35 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
# Tuesday, May 19, 2009
Recently I tried to add a WCF based service channel to my NT-Service to be able to handle client requests from a GUI. I never noticed any problems with that kind of stuff so the more I was surprised as I got that error from the headline... Well the difference was that I usually worked (as developers mostly do ; ) with an useraccount which had administrative privileges. The service instead runs as a Network Service... interesting... even if it would be able to open a port and listen to it - it was not abled to use WCF to listen on an httpBinding. I found a few infos in the web but they were mostly regarding problems under Windows Vista and their solutions were all using netsh - which on my system (WinXP SP3) worked totally different so I skipped those experiments. Finally I found a much better Blogpost which featured some more solutions. On my system I succeeded by using the HttpNamespaceManager and adding the base-address (with that strange http://+:port/ Syntax) with access to the Network Service. So thx for that blog : )
Anyway - it might seem a little strange that a network service program can open any port and listen to it and maybe handle http-protocol by itself but not use some sort of windows-aided http-listening. So this may be more of a feature restriction than a real security issue I think...

Supplemental: I worked around that stuff by now with using a net.tcp binding instead of a Http. So - even it seems possible to add these http-stuff programmatically in the installer - this may be an alternative for someone too.
posted on Tuesday, May 19, 2009 10:39:48 AM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0]
-