I have a few related newbie questions about Entity Framework. (I'm using Entity Framework 22.214.171.124, according to Web.config, and using a "database first" approach).
1) If I change an object in the database (e.g., rename a column in a table or change the output columns of a stored procedure), and then in Visual Studio I select "Update model from database" and "Refresh," the object changes still aren't reflected in Entity Framework. (Unlike with the "Add" tab, the "Refresh" tab doesn't let one select what to refresh, so it's hard to know if it's doing anything when I click Finish, plus the code never works if I rely on the "Refresh.") So my workaround is to create the same object with a different name. E.g., if I had a database object called "item," then I simply create a clone of it in SQL Server named "item1," and then I can add it to EF. That works. So my question is, how do I get EF to work without renaming my database objects every time I want to change them? I don't want to be stuck with so many versions of the same objects.
2) Why are "Result" objects (e.g., the results of stored procedures) not even shown in the diagram? It seems that the only way to update these, if I make changes in the database, is to open edmx's XML and edit that manually. Is there a better way?
3) Since EF stopped writing to Context.cs (even for new objects), I started writing entries directly there. I also noticed that running "custom tool" overwrites the other cs files, but not Context.cs, which is kind of good, because I was able to do things I don't think EF would have been able to create automatically. But seeing that Context.cs is *supposed* to be auto-generated (even though it isn't in my case), I'm wondering if editing it is bad practice. Should I be defining the same partial class in a separate file and then put any custom entries there? That leads to the following issues though:
3a) Does it matter where I put such a file?
3b) If auto-updating of EF stuff *did* start to work again, wouldn't my customized entries duplicate ones that are auto-generated? Or is EF smart enough not to create duplicate definitions?
3c) Or is it better practice to just use regular ADO.NET for anything slightly complicated?
4) Overall, what is the best way to "clean up" Entity Framework and have it just work "normally"? And, apart from avoiding manual changes (which I wasn't even doing at first), what is the best way to prevent it from getting into a weird state in the first place (e.g., weird state = a state where one has to run "custom tool" to have it create any classes, and where it doesn't put anything into context.cs)?