I'm trying to figure out how to make the generated LINQ to SQL classes be marked private instead of public, so that it is not visible outside the assembly. There doesn't seem to be a way to do this in the Visual Studio O/R designer or the SqlMetal tool, unless I'm missing something. Is there a way to do this?
I'm asking because I'm using LINQ to SQL internally as a data access layer in a business logic assembly. I am exposing to clients a separate set of custom entity classes, and I don't want the LINQ to SQL classes to be exposed at all.
It is possible, in the Visual Studio Designer select the class and in properties you can change Access to Internal.
alt text http://img410.imageshack.us/img410/970/l2svs2008access.png
The same principles apply for the DataContext itself (just click in the "white area" of the designer) and change under Properties.
Related
How do I force VS to choose a custom template when creating EF models?
Details:
I built a custom template for generating EF entity classes from models. The solution has many projects with their own models and it is likely more will be added over time.
In order to prevent bugs in the future, I'd like to force VS to choose my template by default when creating EF models in the future. I'd prefer this to be at the Solution level, so that the change is part of the repository.
I have the template exported as a VS Item Template that is basically a clone of the default EF 6.x DbContextGenerator with the appropriate values replaced. I'm able to run it manually by using the "Add Code Generation Item..." option on the model designer view.
I need to write a web site content management system that makes use of dynamic Entity Framework DbContext generation. As an input I get a custom data types declaration (in xml) that my C# code knows how to parse. On the output, I need to obtain the code for the DbContext that would provide a facility to store the provided data type instances as DbSet's in a database.
I can see there is .tt -> .cs Generator in a form of a plugin for Visual Studio. I can surely create code that would generate an xml-based (I assume it is) .tt template from my custom declaration and then generate a .cs DbContext for this .tt. But how do I run .tt->.cs conversion manually from code?
Usually T4 templates are transformed at design time inside Visual Studio. If you want to use a T4 template at runtime, change the value of the "Custom Tool" property of the .tt's Project item to "TextTemplatingFilePreprocessor".
This will make Visual Studio create a C# class from your T4 template that can be instantiated at runtime, where you can pass parameters to it (e.g. your xml type declaration). Calling the "TransformText()" will return the actual output code of the T4 template containing the data classes.
In order to use those classes at runtime, too, you would need to compile the output code in memory.
I'm building an asp application from the ground up using Linq-to-SQL as my ORM. I have a dbml file with a datacontext that includes all the tables of the database (15 for now). If I make changes to the database, by adding a table, adding fields or by changing the data type of a field for instance, how are these kinds of change handled when they occur?
Do I simply drag and drop the new table on the ORM mapper and voila?
Thanks.
Have a look at How to update Linq to SQL dbml file? [best practice] there you will find your answer.
I prefer to use SqlMetal (via a bat file) to fully regenerate the DB schema.
However, you'll find that SqlMetal generates for the entire database. To remove certain tables or relationships; and/or to rename certain tables or generated properties you could look at my blog on filtering items generated by SqlMetal using Powershell.
However, you could of course do it all via the visual studio designer, but that's manual and annoying to repeat for a small change. Or you could manually deal with DBML but that is nasty.
The Visual Studio IDE transfer the changes you do to your dbml file to your ORM classes automatically.
I love Linq but it can rapidly clutter up the namespace with automatically generated types. Usually these automatically generated types are often irritatingly close to other objects leading to many hours of fun and laughter.
In the designer I notice that I can specify the table names, however I can not for the life of me see how to set the row names.
For Example
TableName : User_Table
RowName : User_Row as opposed to "User_Tables"
I swear I've done this before but I can't seem to remember how.
You can do this by manually editing the dbml file in an xml editor. All names are stored separately in the dbml file, but not all are accessible from the designer.
Alternatively, there are third party tools that make handling names etc easier; one such tool is my VS add-in for L2S and EF. It adds naming rule support, mass-renaming, model <-> db schema sync etc to the existing L2S designer. You can download it from http://www.huagati.com/dbmltools/
I've been using this nifty LINQ to SQL tool for a data access layer in an asp.net project. I keep making changes to the underlying tables and in order for the data classes to recognize the change I have to delete and readd the table which has changed. Is there some shortcut to regenerating the data layer?
I've run into this same problem and using sqlmetal is definitely a good way to solve it. One approach is to create a batch file that executes your sqlmetal command and that way you can just run the batch anytime you need update your Linq to SQL classes, but what is even slicker solution is to use Visual Studio's Tools->External Tools function to create a command in Visual Studio that runs sqlmetal with your parameters. This works great and you can even drop the created command onto your toolbar for single-click rebuilding.
You could use sqlmetal which is the command line class generator for linq to sql classes.
LINQ to SQL version 1 does not support detecting database schema changes. The only way to have the generated classes modified is to regenerate them with either the designer or SQLMetal.
Keep in mind that there are not many differences between SQLMetal and the designer, the designer is a more 'pretty' UI for SQLMetal, and hides many of the command line switches.
I use the designer as I'm too lazy to constantly load up the command prompt.
In addition, make sure that you don't write any of your own code into the generated classes, otherwise you'll loose it on a regen. All generated classes are partial which means you can easily add your own extenders in a separate file.
For situations/models where SQLMetal don't quite cut it, e.g. due to different naming conventions in the database and your model, or some other customizations in your L2S model I have an add-in for Visual Studio that adds commands to synchronize your L2S designer with the underlying database [schema]. (plus a bunch of other L2S and EF related features)
You can read more about it, download it and get a 30-day trial license from http://www.huagati.com/dbmltools/
In the past where I've worked, we created a wrapper class to the DataContext that sqlmetal generated. Then we created a thin data layer that kept private the DataContext and all the classes generated by sqlmetal.
If any operations in the software needed information from the database, they had to go through this wrapper layer to get it. In other words, no LINQ to SQL could appear outside of this data layer.
That way, whenever we had to regenerate classes via sqlmetal, only portions of the data layer could break. Much easier to fix one layer where all the data access code is than to change sprinkles of LINQ to SQL throughout your logic or application domain.