Firstly, I've done a build, I've done a clean, I've done a rebuild, of both the project and the solution, so that's not the problem.
When I change my model for some reason the intellisense (in fact, it's not just the intellisense as if I do a build it comes up with an error as well) doesn't work. I have a model under ViewData.Model.ContractCostCentre which exists. VS isn't picking this up, at all. Instead, it's referring to an old one which has since been deleted and replaced with the prior one, this is called ViewData.Model.ContractCCList. So in my view I'm having to iterate over a ViewData.Model.ContractCCList despite this not even existing in my *.dbml file.
This isn't the first time I've had this problem, it seems to happen quite often if I change my dbml file (and it's likely to change as we work on highly progressive systems which are always subject to change).
Any ideas?
can you look into your ????.designer.vb or .cs, depend which language you are using
if you don't see that file, show all file in solution
intellisense is using that file
Kezzer,
At the top of your View, there is part of a line of code that determines what model type the page uses. It should look something like this (my example is in c#):
Inherits="System.Web.Mvc.ViewPage<ViewData.Model.ContractCCList>"
Change it to look like this:
Inherits="System.Web.Mvc.ViewPage<ViewData.Model.ContractCostCentre>"
Related
I'm pretty new to MVC. I've built an EDMX, successfully created the models and am now trying to go through scaffolding to build a controller. The first thing I notice is that in the Model Class dropdown, I have duplicates:
Now, "BillysRentals2" is the name of the project. I don't know where those extras are coming from or where these "Model classes" are stored. It's true I've had to re-do the adding of the ADO.NET Entity thing several times, but even after I completely delete the EDMX and all its contents, some of those model classes still remain, so which are the real ones and where are the others hiding? It's confusing when you create "Model" and you're seeing "Model1" and stuff popping up.
But the second problem is that once I select a class, and press OK, I get this beautiful gem:
And yes, I tried removing the EDMX completely, doing a Re-build, removing and re-adding connections, Rebuilding again, and I'm still getting that message. What's wrong? I'm sure the fact that I'm getting multiple entries above means that there are bits and pieces of my previous efforts lying around someplace that are confusing MVC (not that it's hard to do) but how do I find them and get rid of them to start over?
And P.S. what is the difference anyway between a model class and a data context class?
I had several metadata files leftover from the last time, which had field names that I didn't import this time around.
I've been having an issue with MVC 5.2.3 (and earlier versions back to about 4) using Razor (VB.NET) views where
1) I can't reliably set breakpoints inside a View (doesn't work most of the time even if VS doesn't give me a warning that it couldn't bind, which it often does)
2a) When it hits an exception within a View, the debugger often opens the wrong file (can inspect values fine though!)
2b) Examining the stack trace for the exception shows the wrong file!
3) Occasionally an exception thrown within a View doesn't resolve to any View file at all and the debugger just says it can't find the source and the stack trace doesn't show any file
I've had this on multiple computers running VS2013 and 2015 on Windows 7 and 10. I'm just using the default routes that were set up with the original project template. This has been going on for probably a couple of years now. I think it is affecting multiple projects, but I've mostly been concentrating on one recently so can't remember for sure.
Sample stack trace - note the "no relevant source lines" and the "OperationsMatrix.vbhtml" which is underlined - there is no reason that view should be included and it definitely isn't rendering if there is no exception! The correct view is "AnalyticsReport.vbhtml" (line 122) which is being partially rendered from within "SalesAnalytics.vbhtml" (at line 108). The debugger is also incorrectly opening "OperationsMatrix.vbhtml" on an irrelevant line (the only thing on that line is an End Sub for a lambda method).:
I've had a look in the temp file it is referencing in the stack trace and that seems to be just be referring to OperationsMatrix.vbhtml, so that file seems to be wrong too, but it doesn't actually seem to be executing that, because I can fix the bug in AnalyticsReport.vbhtml and the exception stops occurring.
After changing some code and changing it back again (ie. effectively the same code), it is now generating the following:
Note that there is now source code referenced at the top (from the wrong file - LiveStock.vbhtml) and that file is now appearing near the top of the stack trace instead of one not being found. Lower down, OperationsMatrix seems to have disappeared and it can't seem to find anything for that one. I am pretty sure that the top one should be AnalyticsReport and the lower one should be SalesAnalytics. I'm pretty sure that it should be mapping to Layout.vbhtml as well, which doesn't seem to be working in either of these tries (not noticed/can't remember if it ever does). It seems to be fairly consistent in terms of it either doesn't find anything or it finds another file in the same folder.
I've just had another look at the generated files in the temp folder for that second stack trace. App_Web_grga51wc.3.vb appears to be for a different file and App_Web_grga51wc.1.vb seems to be the one for _Layout.vb. The file refs in the #ExternalChecksum and #ExternalSource directives appear to be correct, so I don't think that the problem is in the code generation or mapping the code from the generated file back to the original using the #ExternalSource directives. The problem seems to be that it is mapping the IL compiled code back to the wrong generated source file (presumably a problem with the PDB file?). I have no idea how or why this is happening, or why it seems to only be affecting MVC projects and nothing else.
For absolute clarification, the views which are being returned are apparently random from the same folder and are not referenced in any way by the view with the bug causing the exception. They are generally not designed to be partial views and often it wouldn't make sense to use them as a partial view - they are usually full, unrelated views which are designed to be used completely independently of the one which is being called.
I've also tried deleting the whole temp folder that it is using and obviously clean and rebuild etc. Also tried disabling the VS profiling tools.
nb. there is no consistency with which view is incorrectly opening. A different one was being opened when I had a slightly different exception a few minutes earlier.
Any ideas?
Finally worked it out!
In the web.config file for the site (the root one, not the one in the Views folder) the \ had an attribute as follows: -
assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
I have removed this attribute and it seems to be debugging fine now! It looks like VS2013 added this when I initially created the project and it has been corrupting the DLLs/PDBs that are generated and messing up the debugging.
To clarify, if anyone else has the problem, the compilation opening tag now just looks like
<compilation debug="true" targetFramework="4.5">
PLEASE NOTE: None of the answers in the link above (which I don't seem to be able to remove) helped me. As I explain below, I had already tried all that stuff
I have a web site, developed in VS2013 using ASP.NET MVC5/WebAPI2, which has several related projects such as a service layer, repository layer, etc. Down at the bottom of the stack is a class library that holds an EF model. I have separated the actual entities into another class library, to allow them to be reused without requiring the model library.
All of this has been working fine. The web site was running, and I could make calls to the WebAPI methods as well.
I just uploaded the latest version to the production server, and all is working fine there. Then came back to VS to carry on work, and when I try to run up the web site, I get an exception
Unable to load the specified metadata resource
Searching around, it seems that the cure for this is to modify the connection string to point to the actual assembly name instead of using the default . I have two problems with this, first is that none of the config files in the solution have been touched today (by me at least, and the file history form source control confirms this), so there's no reason why it should suddenly stop working after being deployed, and second, even if I add the assembly name, I get the same exception.
Anyone any ideas what I can do? I'm completely stuffed now. Can't do anything.
Edit: I tried again to specify the assembly in the connection string, and now get the exception Unable to resolve assembly. I have checked the assembly name in a decompiler, and I'm pretty sure got it right.
Edit again: I just pulled the version that I deployed from source control, and that gives the same exception, so I'm sure this is nothing to do with any files I've changed (or even that have been changed by VS). The version on the production server is still working, but the source code that drives that exact same version gives the exception. So, I'm certain that the answer is NOT to be found in the myriad other versions of this question, but is somewhere else.
Found the problem, and am posting it here in the hope that it will help someone else, as I don't think this was clear in any of the other posts on this issue.
I have a layered solution, with the web project referencing a service layer, which references a repository layer which in turn references the model project. It seems to for EF to work, whichever layer actually causes the database to be accessed requires a reference to the model project. My service layer project, which was where ToList() was being called (thus enumerating the query, and causing the database to be hit) didn't have a reference to the model project, so was failing to load the assembly.
I didn't need to alter the metadata part of the connection string either, as once the service layer had a reference to the model project, it was able to find the resources by itself. Having said that, one thing I did learn from all of this is that you can speed up the creation of the model (slightly) by specifying the assembly containing the resources explicitly, as this saves the framework having to search through all loaded assemblies to find them. I'm not sure if this will make any noticeable difference, but it can't harm.
I still can't explain how this had been working up until now, and suddenly stopped, as I hadn't changed any references, nor the way I was doing the data access. Still, it seems to be working now, which is all that matters.
Hope this helps someone.
I am deploying an MVC3 project to a Mono linux box. I had the skeleton working pretty nice, but when I started filling in some models, views, and controllers, I got the error you see above.
There does not seem to be much documentation on this; what little I've seen suggests that it cannot find my System.ComponentModel.DataAnnotations file, but I've set the dll to copy local and added it to the _bin_deployableAssemblies folder, with no success.
It seems like I'm missing something simple. Any guesses what it is?
It seems the problem goes away if I do NOT include the System.ComponentModel.DataAnnotations.dll file when publishing.
My idea is that it's much easier to edit related code when it sits in single "work" file. E.g. in Rails application when you implementing some functionality you may edit 1 function per file in the following files: integration test, controller test, controller, model, controller helper. So if it would be possible to 1) mark this code fragments 2) automatically collect them in "work" file 3) edit them togather 4) the tool synchronizes (puts back) the changes; it could simplify development process in many cases. Especially if you need to go through many tweek-and-try iterations.
Vim works fine for this. Install the Rails.vim(1) plugin and with the command :AV you can open a vertical split with the accompanied tests/specs, or :RV to open related files like migrations and views (depending on whether you're viewing model or controller). When you're workspace becomes to cluttered, use :only to go back to one file. Splits are the best way to manage multiple related files IMHO. You can even open the same file twice to see two parts of the same file. It's not exactly the same as you are describing, but it comes close.
1: http://rails.vim.tpope.net/
Just open up Vim and open some windows. What's the problem?