I originally had my EF class in a project added to the solution with my MVC app project referencing that project directly in the solution. I added a bunch of scaffolded items with no issue. I recently moved my EF project to a separate solution and am pulling the dependency with a NuGet package in my MVC app, and now when I go to add a new scaffolded item, the EF class nor the EF models are available to be added.
The existing scaffolded items still function fine and has no issues. What am I missing here?
The scaffolding in MVC is very finicky. In particular, it only works on entity classes that belong to the context and, importantly for you, the context must reside in the same project as where you are running the scaffold. In other words, unless you're building a very basic MVC project, the scaffolding will very quickly become obsolete.
The good news is you don't need it. Unless, you're brand spanking new to MVC development, altering the scaffolded controllers, views, etc. will be far more time-consuming than simply creating everything from scratch. There's nothing magical about any of this. A controller is just a class that inherits from Controller. A view is just a text file with a cshtml extension. Everything else is application-specific anyways, meaning that you would have to touch everything that was scaffolded anyways.
Related
I'm currently working on an ASP.NET project which I've not done before, and I need to use Entity Framework to access a database. I have a database already and following along with this tutorial: https://msdn.microsoft.com/en-gb/data/jj200620
I've managed to get Entity Framework to create the classes for the tables in my database but it has created them all in my Views/Home directory like so:
But from my understanding of MVC these should go in the Models directory? Is it safe to just cut and paste these generated files into Models or am I going to run into problems in the future because it's going to still be trying to use View/Home?
It should be safe to move them to Models. The models are compiled, not deployed as website content, so ASP.NET does not care about their exact location.
You will probably want to update the namespaces of the models, though. I'm guessing that the models were created with a namespace like YourNamespace.Views.Home, and you will want to change it to YourNamespace.Models.
Also make sure to update the namespaces to any references to your models (if you have any). You will get compile errors for any references that you missed EXCEPT for any references in cshtml files.
It would be a lot easier to just delete everything created by EF, and add your ADO.NET Entity Data Model (.edmx file) again into the right folder.
On step 3 of the EF guide in your question, when you add the ADO.NET Entity Data Model, make sure you add it into the Models folder. (Right click on the Models folder, then Add New Item...)
I am trying to implement Database first approach using Entity Framework 5.0 but somehow I am not getting it right. I have the following doubts which needs to be cleared.
1.After adding the Ado.Net Entity Data Model a DBContext class 'Model.Context.cs' gets auto-created in the folder under "Model.Context.tt".
Do i need to add DbContext Generator again?(I have found this recommended by others but i could not make out why!)
2.How to scaffold a controller from the edmx files?
Suppose I have an entity, say A (which I want to scaffold to a controller),having one to many relationship with entity B, where will I define this relationship? In the auto-generated model classes from edmx files or do i create classes A & B and define again and then scaffold Model A?
Any help will be very much appreciated. Thank you
Abhatt:
What t4 templates do is generating classes for you and you need to keep them, unless you decide to use another t4 template.
For instance, you may want to design you database but after that decide to use code first to take advantage of code first approach, in that case after designing the database you will add another t4 template named "EF 5.x DbContext Fluent Generator for C#" and that template creates the poco class and all mappings for you.
Whenever you are adding a controller mvc uses scaffolding to create controller's methods and views. However, if you want to have more control on how to generate them, you may install MVCScaffolding from package manager console. Having MVCScaffolding installed, you will be able to customize t4 templates.
For more info check out MVC Scaffolding project on CodePlex:
http://mvcscaffolding.codeplex.com/
also there is another good one:
http://www.codeproject.com/Articles/468777/Code-First-with-Entity-Framework-5-using-MVC4-and
This question has been asked a few times in SO but nothing helped so far in my case.
To an existing MVC project I added a model generated from a database (using database first). Now I would like to add a new API controller. However, neither my new model classes nor my data context class show up in "Add Controller" dialog:
made sure I recompiled my dll
restarted VS (2010)
deleted AssemblyInfo.cs (as suggested in another SO post)
checked with ILSpy to make sure models are in and have an Id
My workaround is to put my models in another dll. However, I think that shouldn't be necessary...
Could it be as simple as a namespace or reference issue.
If they are in different projects then the controller project will eed to reference the respository project.
Can you get to the models by using the full namespace path - you made just need to add a suitable using in the class; typing CTRL+. will give you suggestions.
Hope that helps a little.
I find this site is very interesting and very helpful. I came up with this doubt while programming a project in asp.net mvc. I had to remove few columns from a view which I was using to pull data from the database back to my presentation layer. After removing those columns, I build my project and there were no errors. When I ran it, my project broke with error saying missing related columns as Entity was not changed.
But, my question is that is it necessary that every time I need to update my entity model?. What if I deploy my project in production and then had to remove one column from the view? It will be a hell of task for me If I had to update model, build and deploy it back again on production. Is there a simple solution for this?? thanks for your help
You have to update the entity model every time the database structure changes, what you need to do is to decouple the EF model from the MVC project, if you don't what to work with Ioc, a simpler approach whould be to place the EF model in a separate assembly, when the database changes, rebuild the assembly and deploy it on the server, this way you don't need to rebuild the entire MVC.
Trying to create a MVC User Control in the Release Candidate and I can't see to make one with a codebehind file. The same is true for MVC View pages.
Creating Views in the Beta would produce codebehinds...am I missing something?
Code behind kind of defeats the purpose of the MVC Framework. Functionality should be kept separate from the view, the MVC team felt that code behind pages went against this ideology and therefore removed them.
Your can create a custom helper method to create your control. Also I'm not sure if MVC has view components (Monorail/Castle) but that could be an option as well.
From ScottGu's Blog post:
*Views without Code-Behind Files
Based on feedback we’ve changed view-templates to not have a code-behind file by default. This change helps reinforce the purpose of views in a MVC application (which are intended to be purely about rendering and to not contain any non-rendering related code), and for most people eliminates unused files in the project.
The RC build now adds C# and VB syntax support for inheriting view templates from base classes that use generics. For example, below we are using this with the Edit.aspx view template – whose “inherits” attribute derives from the ViewPage type:
One nice benefit of not using a code-behind file is that you'll now get immediate intellisense within view template files when you add them to the project. With previous builds you had to do a build/compile immediately after creating a view in order to get code intellisense within it. The RC makes the workflow of adding and immediately editing a view compile-free and much more seamless.
Important: If you are upgrading a ASP.NET MVC project that was created with an earlier build make sure to follow the steps in the release notes – the web.config file under the \Views directory needs to be updated with some settings in order for the above generics based syntax to work.*
I answered this question here:
How to add a Code-behind page to a Partial View
Seems this wasn't particularly tricky, and is quite do-able
This answer worked for a Partial 'ViewUserControl' but the same should apply
Ok.
First: Add a Class file with the convention of .cs (i.e. view.ascx.cs)
Second: Add "using System.Web.Mvc;" to the class
Third: Change the Class to Inherit from "ViewUserControl<>"
Fourth: Add the following to the View's header:
CodeBehind="View.ascx.cs" Inherits="Project.Views.Shared.View"
Fifthly: Copy the files out of the solution and drag back in to reassociate the two together
Note: For this to work with a Normal MVC View you just need to inherit the class from "ViewPage"
The whole idea for ASP.Net-mvc was to get rid of the codebehind files...thats why asp web controls didnt matter that most didn't work.But with the changes of getting rid of the code behind comes with a different programming style..The idea is codebehind files are EVIL:
http://stevesmithblog.com/blog/codebehind-files-in-asp-net-mvc-are-evil/
the whole idea is to make sure people remember they are using asp.Net-mvc and not asp.et web pages. take alook at this link ,it explains it a little better:
http://blog.lozanotek.com/archive/2008/10/20/Visual_Studio_Templates_for_MVC_Views_without_Codebehind_Files.aspx
I think this tutorial is what you are asking.. but not really sure what you want..