This project has moved. For the latest updates, please go here.


Database objects with names the same as language keywords produce invalid code


Database objects with names the same as language keywords are not handled elegantly. I realize this is a known issue but it's also a big blocker for our usage. I could edit the template myself however I feel this would be counterproductive since we are not allowed to submit patches for inclusion according to Damien's response to different proposed patch. Is there any way this can be addressed in the available template so the @ character is used to prefix properties or class names that happen to collide with language keywords such as "do", "class", or "int". It appears there is a built in method that could help CodeDomProvider.CreateEscapedIdentifier which may make this dynamic to the target language.
On the other hand, If this project is no longer being maintained, maybe we should consider starting up a community supported fork of this project here on CodePlex.
Closed Mar 27, 2013 at 4:20 PM by damieng


damieng wrote Dec 7, 2010 at 2:58 PM

The template is meant to be a good starting point and easy to edit.

Unfortunately wrapping every single piece of metadata driven output in a method that avoids naming makes the harder for everybody to read and edit.

If enough people want this feature over readability then I would add it.

kainhart wrote Dec 7, 2010 at 4:25 PM

My thoughts are that this template should at a bare minimum be able to match the features of the default SingleFileGenerator that is included with Visual Studio otherwise it makes it harder for those who would like to transition into using these templates as a drop in replacement. I did modify my template to correct for these names but then I ran into problems with the Member property being used not only to fill the member name of the template but also to fill out things like methods that have a reference to the member name such as OnMyFieldxxx. So in these cases the @ symbol in the middle of this word is not going to work so I just stopped there because it started taking time away from my real work. I also noticed that plurals didn't seem to be handled the same as the default code generator from Visual Studio but I don't remember at which level. If we can get these templates on par with the default generator in Visual Studio then I would love to use this generator to open our LINQ entities to some custom generator and even more so I would be interested in the separate file per entity feature that is already built in.

Thanks again for sharing these templates and I hope to see some improvements made along the lines mentioned above.

kainhart wrote Dec 7, 2010 at 4:29 PM

BTW, I would recommend creating a new property on the Column class that exposes the name as it is to be used within references (ex. MemberNameReference). That way in the template when constructing method names that refer to this member you can use that property but when actually filling out template for the definition of the property itself or when that property is being referenced in code then the Member property could be used instead. This takes a lot of the rudundant work that would have to be done in the code for producing Camel or Pascale cased forms of the member name as well for use within name references.

Codepoet77 wrote Mar 22, 2011 at 7:03 PM

Hi Damien. Thanks for the hard work on this and I appreciate the effort but I am also running into this issue. Are you able to resolve this one?

Though the following is true..:
"Unfortunately wrapping every single piece of metadata driven output in a method that avoids naming makes the harder for everybody to read and edit. "

It does not work when columns are named after key words. Is this something that you would be able to fix. We are actually using your templates here at work and have run into this issue on a project. Let me know if this is something that you think you can correct.


damieng wrote Mar 23, 2011 at 5:17 PM

As I originally said in this thread yes it could be done but it would come at the cost of readability. The goal of this project was to provide people with a good starting point to make their own versions of templates. Wrapping every single variable emit in an escaping function really grates against that.

kainhart wrote Dec 7, 2011 at 3:57 PM

Has anybody else who has run into this problem found any other projects that provide a more full featured approach that can match the built in Linq to SQL code generator? If so I would rather reuse what somebody else has done instead of re-inventing the wheel. Perhaps we should fork this project and extend it as needed for that reason?

kainhart wrote Mar 27, 2013 at 6:18 PM

I noticed this issue was closed but I don't see an explanation of why? Is it By Design, Wont Fix, or Fixed?

damieng wrote Mar 28, 2013 at 6:32 PM

I responded twice already to this post stating the goal of the template is to be an easy to use starting point for people needing their own LINQ to SQL code generation. Adding escaping all over the template to handle keyword conflicts/string escaping etc. would be counter to that goal.

kainhart wrote Mar 28, 2013 at 9:34 PM

Understood, I was only asking the question because your last response was from two years ago and you added no comment when you closed the issue. Since CodePlex doesn't seem to have any separate way to indicate the resolution to the issue other than it was closed I didn't have any clear way to know whether you or somebody else had fixed the issue regardless of your original attitude about whether it should be within the scope of the project. Thanks for clarifying now though so that I don't have to hunt through the source code change list for my answer.