I am using Linq2Sql to access my database which is fairly large. (67 tables)
It's quite a pain in the butt to work with currently because it takes ages for the "MSLinqToSQLGenerator" to generate it's classes and finally finish compiling.
Are there any ways to speed up that process?
Like, is it possible to cache its generated output as I'm rarely touching the databasestructure?
Thank you for reading.
Moving your model to a separate assembly.
When your model is included directly in your application's project and you generate views through a pre-build event or a T4 template, view generation and validation will take place whenever the project is rebuilt, even if the model wasn't changed.
If you move the model to a separate assembly and reference it from your application's project, you can make other changes to your application without needing to rebuild the project containing the model.
Note: when moving your model to separate assemblies remember to copy the connection strings for the model into the application configuration file of the client project.
For more Information Check Performance Considerations for Entity Framework
Related
Is it possible to have entity framework dynamically add/remove tables/columns in its DbContext without recompiling the project ? The use case is EF inside a GUI app and the DB schema may be changed behind the scenes over the lifetime - we don't want the GUI app to be recompiled on every DB change - it should just visually show the new table classes (i.e. Schema) as well as a few controls like type, property name etc.
It's technically not possible if your GUI app works with your database without some detached "api" - real web api, wcf service, etc. Even if you disable automatic migration for project and will manage to make your application think, that database is up-to-date (which can probably happen with some magic, dynamic DLL compilation, etc.), you have a big possibility of getting something funky - changed FK, PK, restrictions, constraints, data types, etc.. This will cause unexpected behavior for Entity Framework, and bring only grief.
Only in this case you can do it without affecting real GUI app - you just re-roll external project and voila - it works, if you properly set up your DTOs and methods. Otherwise, if your API changes uncontrollably, you will get DTO mismatch problems, which you will have to handle with versioning, etc, etc.
It's overall a bad idea to change model backing your application in any casewithout recompilation, since C# is not a dynamic language.
Entity Framework does not do that. It would be custom solution, pretty expensive.
I am having a very hard time trying to find an example of creating a project data source which points to an entity framework model that is located in a separate project. To be more specific I have a simple class project which only contains my entity framework model which I re-use in many projects with no problems.
In a new project I would like to utilize some of the design time data binding facilities of a few commercial data bound controls to speed up some of my development tasks. If I go to add a new project data source, I can only generate a new EF model or add an empty model I cannot add an existing model from a seperate project.
I have tried copying both the connection string and .datasource files from the EF class project but nothing shows up in the "Data Sources" window. I have seen many many articles on how to move the EF model to a seperate class project which works just fine, I just haven't found anything on creating the "design time" project datasource that points to it.
Can anyone point me in the right direction please? Thank you very much in advance.
I feel pretty dumb about this but I figured out the problem and maybe it will help someone. The project I just happened to be working on is a 64-bit only project. And I'm sure you can guess the rest if any part of the project or any of the assemblies are 64-bit only, anything to do with the datasouces window simple does not work at all. It is a bit annoying there are no errors or logging about it anywhere but what can you do. Thanks everyone who tried to help I appreciate it.
EDIT :
This question is not about compiled queries, it is about generating the EF database view at compile time.
From the ADO.NET team blog: Exploring the Performance of the ADO.NET Entity Framework - Part 1:
View Generation 56%– A big part of creating an abstracted view of the database is providing the actual view for queries and updates in the store’s native language. During this step, the store views are created. The good news is there is a way of making view generation part of the build process so that this step can be avoided at run time.
The first database call in my web app takes about 2.5 seconds instead of ~30 ms for subsequent identical calls.
I generated a precompiled view source file using the T4 template from the ADO.NET team blog, but it has made no detectable difference.
The T4 template takes about 2.5 seconds to run and the generated code compiles.
What am I missing?
Fixed it!
The Generated View derived from EntityViewContainer must be in the assembly that contains the STOs Self-Tracking Objects, not the one that contains the edmx model.
Your first call to your application after a build, the web server will have unloaded the application, and the first call "starts" the application again, and everything that is associated with that. This has nothing to do with pre-compiled views. Therefore, the first call will always take longer as the application is loaded.
Incidentally, the same thing will happen on your production server. An idle worker-pool might well unload your application, and the next call will load the application again, taking significantly longer to perform than usual requests.
I recently copied a MSSQL2000 DB to a MSSQL2008 DB. Afterwards I ran a script to update all the text/varchar fields in the tables to the same collation as the model db. However, all my copied views still are using the same collation as the previous db. The easiest way I found to fix this would be to have MS SQL Management Studio create the DROP/CREATE scripts for these views. However, certain views depend on other views so you need to make sure to DROP/CREATE these views in the proper order.
So my question is:
How would I create a script that traverses, depth first, the dependencies of each view and then on the return trip drops and creates each view?
I'm assuming that this will use SMO. I will be writing the script in C#.
Can you not just iterate through and execute sp_refreshview dynamically? This will achieve the same result: updating the view for the new base table definition.
You aren't using WITH SCHEMABINDING (otherwise could not change tables) so dependency or depth does not matter.
in cases like this just run the script a bunch of times (SSMS f5), eventually all the child views will exist when they are used by a parent. You can tell when everything is good, as there will be no errors.
Try DBSourceTools. http://dbsourcetools.codeplex.com.
This utility uses SMO to script all database objects and data to disk (using DROP / CREATE) scripts.
It also automatically builds a dependancy tree and will re-create database objects in the required order.
Once you have scripted your 2000 DB to disk, create a "Deployment Target" database for your 2008 database.
You can then create a full set of patches to change / upgrade / rename all of your views.
DBSourceTools will re-build your database for you, and then apply all patches in order.
It's a reliable, repeatable method of version control for databases, and allows you to test and version control these patches.
When you are ready for release, simply send all of the patches to your DBA, and get him to run them in order.
Have fun.
My question might be little bit different or basic for advanced users here.
I have a web application which is customizable by administrators. This means, the admin can add new table schema or edit table columns, add new table columns etc. These changes are mapped to our logical objects (much similar to EDMX) which is published after the change. While publishing we generate Stored procedures with necessary changes that are required.
From UI we use these Logical objects to connect DB (using COM which understands the mapping and executes appropriate sprocs and views etc). Now i am thinking to use EF for replacing the Logical objects model which we are having currently. I can create the EDMX files (csdl,msl, ssdl, cs files) dynamically but i am not sure how to compile them and package the classes into DLL dynamically. This means, when i click the button the all edmx related files will be created and DLLs must be created based on CS files and the website must be able to access the new changes in the code.
Can you help me how to automatically and dynamically compile the cs files. I will not have the source code of other files (like default.aspx and others) at customer's end.
Thanks
Albert
Bepenfriends - rather than attempting a CSC from a shell, consider using a CSharpCodeProvider.CompileAssemblyFromFile.
One thing to be careful of: if you compile code and then try to compile it again, you may lock up on the assembly that was created. For this I created an AsyncCompiler which creates a new AppDomain, compiles in there, and then unloads the AppDomain.
It's some pretty hairy code but I'm doing this (generating the AEF XML files, generating code from them, and then compiling everything into an assembly) and it works well. The only thing I don't have quite right is dynamically importing stored procedures - my SSDL has them but not the CSDL or MSL. The search for a solution led me here.
I hope the keywords here are enough to set you off in the right direction.
I don't really have a definitive answer for you just yet - but two potential solutions you could look into, possibly in the near future:
1) There's a set of CodeSmith templates called PLINQO which generate your Linq-to-SQL model (DBMX) and its associated *.cs files from your database. I asked them about Entity Framework support myself, and they confirmed to be working on it - so maybe they'll have that some time soon.
Since those are code and model generation templates, you could definitely take those for Linq-to-SQL and tweak them for EDMX, too. A bit of work, but definitely possible. Once you have the *.cs files and the *.edmx model, you can generate a resulting assembly from it using the CSC (C#) command-line compiler that's installed on every machine which has .NET installed.
2) With .NET 4, the new Entity Framework 4 will include T4 templates (another code generation technology) which will allow you to customize your code generation. Same story applies here - you could externally generate your EDMX model and associated *.cs files for the classes and generate an assembly on the fly from those templates.
See another blog post on that topic, and you should find lots of information when gooling (or binging) or "EF4 T4 templates".
Hope that helps at least a little bit!