I have a .cshtml file in my App_Templates folders that builds but I have heaps of errors.
I get it saying things like:
The name 'Model' does not exist in the current context
The name 'ViewBag' does not exist in the current context
HtmlHelper does not contain a definition for 'TextBoxFor' and no extension method for 'TextBoxFor' accepting a...
It is strange because other cshtml files in other directories are fine and have no red line errors. I have restarted VS, restarted my PC, tried adding a few assembly lines from other questions and rebuilding. I have tried for the past day but can't fix this annoying thing.
Any helpful hints or tips would be great. If you require any specific information please let me know and i'll edit this post.
Just wanted to close this thread for good.
The issue was as #Georg Patschieder suggested in the comments on the initial questions. The wrong folder was used and once I moved the *.cshtml files to App_Code and changed the respective references everything worked great.
Related
In vs2019, I added a new razor component to a working and essentially brand new Blazor App project. I renamed the file for my new razor component and noticed index.razor still referenced <oldComponentName/>, so I updated it to <newComponentName/> to match the new file name.
I see the error: Found markup element with unexpected name 'newComponentName'. If this is intended to be a component, add a #using directive for its namespace.
I built, rebuilt, and searched for a "map" of file names to component names that was out of date or something - no luck. There's no other namespace that I've (knowingly) introduced, so the #using guidance doesn't seem relevant.
At the moment, I happen to want my file names and component names to stay aligned. What am I missing here?
I had to restart my Visual Studio. No additional fixes were required. The problem seems to be some cached data.
Checklist:
Your component name should starts with a capital letter, as Counter and not counter.
The file name without extension is the name of your component
Thus, if you name the file name Counter.razor, your component name is Counter,
and it should be used like this :<Counter />
The error you received may also be attributed to failing to import the namespace where your component resides (in case you've defined it in a new folder you added to your app).
Restarting VS often works. When it doesn't I've found opening the component and resaving (maybe with a superficial edit) can resolve
This problem still exists!
I also got the message advising to use an #using directive. I had also tried closing the Solution, do Cleans, Builds and Rebuilds to no avail.
Restarting didn't work for me, however, in fact having exited and re-entered VS neither component was being recognised.
I decided to add a new component from the Add template with the original component name and copy over the contents of the renamed file, at which point IntelliSense decided to recognise both versions, and things then ran as expected.
So this was quite a hilarious error and was quite difficult to trace, so I'm going to chuck everything on here in case it happens to anyone else;
While working on a website in production, its name changed. I noticed that the IISExpress instance displayed not only the new name, but a '\' and the old name as three separate instances.
As I was attempting to add log4net to the project, I attempted to use this line in the web.config:
<log4net configSource="log4net.config" />
Which caused the following error on app run:
the configSource file '[file]' is also used in a parent, this is not allowed.
the configSource file is also used in a parent, this is not allowed.
This was perplexing as I had not used this source anywhere else, and no matter what file I changed it to, I got the same error.
log4Net worked fine when I defined it entirely within my web.config, but that's not what I wanted, so I investigated further. Interestingly, a colleague who'd just been brought onto the project could run the app fine with the separated config, but I and another dev who'd been working on this project for a while could not.
How can I and another colleague with exactly the same setup have a failing app with the same config as someone with a fresh checkout have it work fine?
The web.config file is "composed" when it is read by the application by scanning the file system from the current directory up to the drive root and by looking in a number of pre-defined places (such as the location of the Machine.Config and the default ASP.NET config.) If you're using Virtual Directories on the same website in IIS, things can turn even more interesting.
Any of these files can define configuration sections and can possibly externalize the configuration, and thus cause the error message you're seeing.
The following doc on MSDN outlines exactly how the configuration is being parsed and composed:
https://msdn.microsoft.com/en-us/library/ms178685.aspx
It turned out to be that IISExpress had saved the previous settings in a .vs folder at solution's root level, and all three of those instances were using the same config, and looking for the same file, hence the error.
The solution was as follows:
In the web-app's project, reset the web properties to look at the root site (\ instead of \newname\)
Trash the entire .vs directory
Restart Visual Studio and Reload the project.
For different versions of VS, the .vs folder is in different locations on your machine.
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.