The view 'Index' or its master was not found

Question

I'm new to the C# MVC project type and when I created an empty C# MVC project, I noticed the following error:

The view 'Index' or its master was not found or no view engine supports the searched locations. The following locations were searched:
~/Views/ControllerName/Index.aspx
~/Views/ControllerName/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx
~/Views/ControllerName/Index.cshtml
~/Views/ControllerName/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml

I do have the "Index.cshtml" file under the Views folder. Why does the MVC engine not look directly under the Views folder? How do I solve this problem?

My RouteConfig.cs contents are:

 routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = <ControllerName>, action = "Index", id = UrlParameter.Optional }
            );

My controller contents:

 public ActionResult Index()
        {
            return View();
        }

Him

Make sure the file exists on disk and not trust Visual Studio's file map. This might happen if you use source control and other commit the csproj but the cshtml. – Rahal

Answer 1

MVC looks for views (like Index) under the views folder but they also have to be under a folder named after their controller (with a few exceptions like partials).

So this is the structure you want to follow in your project

Controllers (folder)
    HomeController (.cs)
    AccountController (.cs)

Views (folder)
    Home (folder)
        Index (.cshtml)
    Account (folder)
        Index (.cshtml)

Sindysine

Answer 2

I've had this problem a few times before and it can be any of the other answers, but it can also be the Build Action that is causing the issue.

If you right click on the .cshtml/.vbhtml file that you are having a problem with, select Properties, and in the properties window set the Build Action to Content then this can be a solution to your problem.

Veneer

Answer 3

The MVC engine search for a view under Shared or under the folder that is named like the prefix of your controller class. So if you have ABCController you need to have your Index.cshtml view under the folder Views/ABC.

PS : In your example you have a suffix to your controller name (ControllerName), I don't think it is a good practice, always name your controllers [Name]Controller

Goebel

Answer 4

If you manually deployed the code to an instance of IIS, make sure that the App Pool Identity that is being used to for that application in IIS has rights to the folders in the application.

A good way to diagnose if it's something wrong with your code or something wrong with your IIS settings is to run it in the VS 201X debugger. If it runs there, but won't run under IIS directly, it's a good chance that the App Pool Identity security is jacked up.

Recapture

This was the issue I had, thank you. I updated the app pool identity to use the same user as my website and now it works. – Goliard

Answer 5

When a view is returned, it expects that an associated .cshtml file is in the same view folder structure as the controller layout for that area (if no areas are in use, then there is only 1 view folder and 1 controller folder). The controller name will be the folder name in the views folder, and the actionresult name will be the expected name of the .cshtml file.

Luckily there is an easy way to remedy the situation where the view file is missing. Right click on Index for your action result, and then select Add View. Click okay, and it will create Index.cshtml for you inside of the correct folder. Now when you run the project, and navigate to Index, that is what you will see.

Rebba

Answer 6

You may have old/bad ASP.Net assemblies in your build.

If you've made sure you have your Controller, namespace and View names all in the right place, there's a good chance your MVC/ASP Assembly is having problems working with the current Mono environment.

If you've tried the tricks to copy all the .Net assemblies you can find and tag them into your bin, there's a good chance Mono or its configuration is not melding correctly - and you don't need to do that anymore. I had this problem when updating a machine to the latest Mono build. I wiped these assemblies from my bin, and NuGet'ed the latest assemblies in the Mono MVC Packages folder.

First thing you'll see is:

• Microsoft.AspNet.Mvc
• Microsoft.AspNet.Infrastructure
• Microsoft.AspNet.WebPages
• Microsoft.AspNet.Razor

This will resolve these problems.

Globigerina

Answer 7

I had a virtual directory that wasn't correctly referencing the actual directory. (On Windows) I fixed this by going into IIS (Internet Information Services Manager), and right clicking the virtual directory that wasn't being correctly referenced (In your case, Views). Virtual directories will have this little icon next to them:

Right click and then select Manage Virtual Directory > Advanced Settings. Ensure the Physical path matches where you think it should be going:

This isn't going to apply to all cases, but it's a possible match for some instances.

Stent

Answer 8

I know this is an old post but I ran into this same situation running on Ubuuntu 16.04 and Mono 4.2.1 and none of this helped. I started digging into other things and after a week I found out that for some reason Microsoft.Web.WebPages.OAuth.dll was causing this error. after deleting that dll and removing all refrenses to it (I'm not using the open auth anyway) everything immediately started working even using simple membership with MySQL. So I wanted to post this here in case someone else runs into this same situation on Mono and Linux because this comes up in google.

Gaven

Answer 9

A useful diagnostic step is to right click inside the Controller's Action, choose "Go To View".

If Visual Studio can find the view, then it's probably in the right folder, so re-check your URL. For example, if using an Area then the area name should be in the URL:

/Area/Controller/Action

Tannatannage

Answer 10

I ran into this error on my older style .NET Framework 4.8 WebAPI when I tried to navigate to the /Help URL (uses Microsoft.AspNet.WebApi.HelpPage v5.2.9) even though the actual API produced correct results.

I cannot quite put my finger on it, but, simply regenerating the IIS site instance (I do not mean restarting the site, but rather drop and recreating the entire site) fixed it for me. I've encountered it twice this week, and here are my guesses:

• the first time this happened, me and a colleague were standing up a new Windows 2019 server. I had already copied my files to the server, and set up the site in C:\inetpub\mysite prior to the infrastructure guy turning on all the required features for IIS to support ASP.NET. So, somehow when he turned on the ASP.NET support, it didn't properly recognize my pre-existing directory as a fully legitimate thing. Drop and recreate fixed it.
• Now, today, the same server has been moved into our sandbox environment. IIS is fully setup this time but I get the error again. This time I think it is due to my copying the files directly from a *.zip file rather than extracting the files first. IDK if there's something untrusted about the files if they are directly dragged from the "zip window view".. but once again, re-creating the site worked (recreating from a set of files that were extracted first, then copied into C:\inetpub)

Incompetence