I've just made my database using Entity Framework Code First and everything is working great. However I want to see the schema of the entities; almost like generating an EDMX from the code first, but it doesn't have to do anything.
How do I do this I hear there is a nuget package for it, but i'm not finding it.
Thanks for the help!
The tool is called Entity Framework PowerTools CTP 1 and it is not NuGet package. It is standalone installer available on VS Code Gallery.
If you're using the Code First approach, you don't have .edmx schema/mapping files. The relationships between entities can be found within the POCO models themselves.
If you definitely want to use .edmx files, however, you can use the Database First approach. In that case, you would create your database manually and let the entity data model be automatically generated for you.
Related
We are automatically creating solution files (sln) and solution filters (slnf) during our CI.
Since we are not working inside Visual Studio we cannot use the DTE to work with Therefore we are using the Microsoft.Build nuget packages.
Everathing works fine, except that there is not possibility to create a solution file programmatically. It seems that I have to create it fully manually by stiching blocks of text.
Is there a better way to do this?
Since my comment helped, posting it as answer
There's MvsSln which is very powerful in editing. Also there's mine little project that has very simple API - bunch of immutable types and saveToFile function
I have the situation where I'm working in a new database, built using a Visual Studio 2010 database project, which has a number of synonyms defined which point to our legacy database.
Our plan is to create views over these synonyms; the tables being referenced are horrible, so the views will mangle the data into a better format; after that we will use Entity Framework to provide an ORM for these views (the idea being that we can then swap the views for real tables as we migrate data).
Problem: I can script the synonyms in the database project with no problems. However, when I try to create a view which references these synonyms, I am confronted with an error similar to:
Error 1 SQL03006: View: [dbo].[Person] has an unresolved reference to object [dbo].[ma_contact].
...where [dbo].[Person] is the new view and [dbo].[ma_contact] is the synonym for the legacy table.
Workaround: Place all view creation scripts in Script.PostDeployment.sql, doing the if-exists-then-drop-then-create logic manually.
This is less than ideal, although it's livable-with for now. Anyone have any ideas as to how to do these views "properly"?
Have you tried adding a database reference to your original database? You'd have to extract its format into either a dacpac (for SSDT SQL Projects) or a DBSchema file (for DB Projects). Once you've done that, store it in some place the project can find it. We used a "Schemas" folder at the root of our DB Projects so all projects could reference it. In your project, right click the "References" folder and add a Database Reference. Search for your DBSchema/Dacpac file and use that, along with the name of the database. That should let your synonym resolve properly so you can reference it in your views.
If I want to Large Scale Generation and define
Application = Framework (binary core components) + Generated Code + Custom Code
How would I go about creating code generation framework using scaffolding to generate multiple projects and associated files from some metadata (let's say a DSL model defined in a solution folder)
I know that I can use MvcScaffolding powershell cmdlets to add files to the current on another project.
I need to know if I can add a new project (Class library, Web appication) to the current solution from some kind of project template, apply source transformation and possibly merge some custom data. That would allow additional files to be added and I would prefer that both creation of the project and adding some files initially be done in one powershell line based on some input parameters (let say the name of some DSL model, XSD schema, XML data)
Could I just create a new solution and invoke some scaffolders? Are there scaffolders at a solution level?
I would like to have a scaffodling framework resembling software factories (Web service software factory). Any samples, ideas, articles?
Thanks
Rad
I don't see any reason why not.
Your T4 templates can access EnvDTE and so do all sorts of fun VS automation, and of course the .ps1 powershell scripts can (I guess - I am no powershell guru) do pretty much anything you yourself can do on your box.
But out of interest why would you want to generate whole projects? i.e. are you sure that is time saving?
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'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.