We Keep Coding

How find references for MVC controller methods in Visual Studio

Coming from a long period of WebForms development, I recently began working with MVC. One thing that struck me, is that since controller methods are not called directly from code, Visual Studio won't pick up any references to them.
I understand the reason why there is no reference count, but it can be problematic sometimes. Let's say I rewrite a controller method to accomodate some new requirement, perhaps a certain call to the method needs additional data or a modified result. But perhaps that method, or endpoint if you will, is being called from several places, and the change I made breaks the result handling for those other calls. I would like to be able to easily find all the code in my solution, which is going to invoke the endpoint.
Currently I tend to copy the method name and perform a regular text search in the entire solution, which works rather well as long as the method name isn't too generic. If the method name is "Index", it can be a long day.
Are there any recommendations on how to simplify this, such as coding conventions, plugins or otherwise? I.E. how can I locate from where the endpoint will be invoked?
I currently use Visual Studio 2017 Enterprise, but solutions working in other versions as well are preferred - to make the answer useful for as many as possible.
Thanks in advance / Culme
UPDATE: I learned a lot based on the comments and replies I got. Apart from what is mentioned below, I also decided to try and keep my controller method names unique and identifiable, to simplify finding where they are being used. As an example, instead of just "Index", I'll try to use "Fidgets_IndexController" or something similar. That way, a simple text search will go a long way for locating calling code.

Controller methods are not directly referenced from any part of the code (therefore 0 references), but they are dynamically invoked based on RouteTable which maps controller methods on startup RouteConfig.RegisterRoutes(RouteTable.Routes); in global.asax "implicitly" which would map them as /controller_name/action_name or these can be changed by either editing
RouteConfig.RegisterRoutes(RouteCollection routes) or using attributes:
[Route("myAction")]
public ActionResult MyAction() {
...
}
which would bind it to /myAction (without controller name)
further reading:
MSDN - Understanding MVC Application Execution Process
Lifecycle of an ASP.NET MVC 5 Application
ASP.NET MVC Routing Overview

One of the options is Resharper - it more or less can determine where you use Html.ActionLink() or Html.BeginForm() that points to a controller action. But it won't detect any posts/redirects done from JS.
Also another thing you can do is use T4MVC to make the links from views statically typed, so you can search on references.
Text search through the solution can help, but not always good as you already discovered - how many references to string Index do you have in an average MVC project? So this will help with distinctive controller/action names, but not with common names.
Apart from that you are on your own. If you try doing something clever, like in JS concatenate strings to give you the right endpoint - you are in trouble.

Another option if you know the application fairly well. Put a breakpoint on the controller action and then run some tests of the application.

asp.net MVC correct place for controllers for shared partial views

Where is the best place in the project directory for the controllers for Shared partial views?
I have found similar question to: ASP.NET MVC: Correct place for Partial Views?
I can't decide if it is better to do something like /Controller/Shared/CONTROLLER_FOR_PARTIAL_VIEW or just create its separate folder like /Controller/CONTROLLER_FOR_PARTIAL_VIEW
The partial view is specifically for dropdownlistfor, and the model wont be used for anything other than to populate the dropdown. So if a site has many dropdown lists or just partial views in general, a shared folder seems to be the best option. If the preferred way it the Shared folder, do you use one controller for each partial view, or one controller for all partials? I appreciate any thoughts or feedback, thanks!
EDIT: To be clear, I m specifically asking about the directory for the CONTROLLERS not the VIEWS. Thanks!

In one sense, it doesn't matter. There is no true standard or convention for this, so you have the freedom to do it however it makes the most sense to you and your application.
Having it under something like Controllers/Shared could make sense, if there's enough of these that that is worthwhile and it adds value to keep them separate from regular controllers. However, in terms of a project, everything is essentially shared, so there's no true distinction here. Personally, simply having it named something distinctive is probably the best route. For example, I have a number of child actions in one of my projects that are used in various parts of my layout. As a result, I created a LayoutController to house these.
The one thing to keep in mind is that, if you're using standard routing, any controller will be available to the routing infrastructure, regardless of where it's located in your project tree. You'd have to pretty much just know how to get to it, but if you named your shared controller something like SharedController, then with standard routing, its actions would be available via /shared/action. For things like child actions, this is easily solved by using [ChildActionOnly]. By adding that attribute to your child action, it will be divorced from the routing infrastructure for URL requests. Internally, MVC will still be able to get to it for the purposes of rendering it for a view, though.

Projects I've been on it was at /Area/Controllers/SharedPartialController.cs and with that naming the view was at /Area/Views/SharedPartial/_MenuDropdown.cshtml
Hopefully you're using "areas" in your MVC project, in which case I would suggest doing one shared controller per Area.
I.e. /Order/Controllers/TabsPartialController.cs for one that relates to Order area, and then /User/Controllers/NavTabsPartialController.cs etc.

What's the best way to change how Areas get created in Razor MVC?

I am transitioning to using Areas in a project, and each time I make a new one I have to change a few things to make it fit in with how I'd like things to work. The changes involve:
Removing one of the folders that gets created
Modifying the web.config file slightly
Adding a new file or two with some defaults
Modifying the AreaRegistration file slightly
I would rather not have to do these same things every time I create a new area because I'm afraid that the convention will be forgotten and something will get messed up. Is there a way to modify the defaults for New > Area? Or perhaps would it be possible to make a new file template that does what I'd like?

I am transitioning to using Areas in a project
I have been doing something similar for a few months now, but starting with an old WebForms project, adding MVC components via VS 2013's Add -> New Scaffolded Item... feature, in order to leverage MVC's structure and routing, on the server side. I have also been incorporating WebAPI and SignalR on the server side. I am definitely still a beginner, but being maybe a little further along in a similar process, here some of my thoughts and questions about what you want to achieve:
Removing one of the folders that gets created
Modifying the web.config file slightly
Adding a new file or two with some defaults
What environment are you developing in? For instance, if you're using VS 2013's scaffolding you can most likely modify the T4 templates to prevent or redirect the creation of folders, classes, and such. Here is a post addressing where you might find those templates, and here is just one of many intros out there for T4. The path to the templates on your machine will vary based on the VS version. By modifying or creating new templates you should be able to accomplish all 3 points above relatively easy. If you are working in such an environment I will try to expound on exactly how you might go about modifying the out of the box templates (there are probably already plenty of posts that you could refer to which would do a better job though).
Modifying the AreaRegistration file slightly
If you are working with MVC 5, or later, I would recommend using attribute routing. This seems more standard when working within the API paradigm (inheritting from ApiController instead of Controller), but I have found extending this to traditional MVC controllers to be very useful.
Assuming MVC 5, I would recommend modifying AppStart\RouteConfig.cs's RegisterRoutes() method, to enable attribute routing and then add a catch-all route such as:
routes.MapMvcAttributeRoutes();
routes.MapRoute(
"NotFound",
"{*url}",
new {
controller = "Error",
action = "Index"
});
At that point I would delete the xAreaRegistration.cs files, and remove the call to RegisterAllAreas() from Global.asax, but you don't have to go that far. Then I decorate my controllers' classes (wherever they live) and their methods, with attributes as needed. Using attribute routing I've been able to free myself from the traditional MVC conventions. I can still fall back to them, but I can then place my controllers anywhere in my project, and easily define their actions' routes.
That being said, you should probably follow some organizational standards for groups of similar routes, so that as the project grows you don't find yourself wasting a lot of time searching for all controllers/actions matching some set of routes.
Here's a simple example of how this actually translates from URI into method call:
If I had Controller ctl with action act, logically in Area ar, the URI being http://localhost/ar/ctl/a/1, would be routed to MyControllerNameDoesNotMatter.Index(1), below, by using attribute decoration such as:
[RouteArea("ar")]
[RoutePrefix("ctl")]
public class MyControllerNameDoesNotMatter : Controller {
...
[Route("a/{optionalParamDefaultsToNegativeOne=-1}")]
public ActionResult Index(int optionalParamDefaultsToNegativeOne) {
...
}
}
This way of looking at Area is more logical than physical, in that the MyControllerNameDoesNotMatter.cs file does not have to be in the Area\ar\Controllers folder. Since adopting this I have actually drifted away from using the Area scaffolding, other than to lay out application modules at a very high level - think sub-application that could be a stand alone SPA.
I have tried to make the "catch-all" route attribute based, and remove it from RouteConfig.cs, but I have not been able to do this successfully. The issue is route precedence. It works fine as a catch-all for invalid routes. But for a valid route, multiple (2) routes end up being matched because the two attribute routes have the same order of precedence. Whereas, with the catch-all defined in RouteConfig.cs, after registering all attribute routes, the attribute route takes precedence. I have found mixed answers that attempt to address this issue. There seems to have been a Number or Order parameter for the Route attribute at some point, but I have had no luck with that. This seems to be an unresolved issue. Just one of many SO questions, which have gone unanswered.
Edited to account for mvc4 tag
I had not seen the mvc4 tag prior to posting. There are nuget packages available that will achieve much of the same functionality, such as scaffolding and attribute routing for earlier versions of MVC.

Folders in Controllers directory in ASP.NET MVC 4

I'm kind of new to ASP.Net MVC 4. I'm working on an app that will have a lot of routes. With that in mind, I'm running into naming conflicts in my Controller. Because of this, I've decided that I want to split up my Controller into multiple controllers. In an attempt to keep things clean, I feel I have a need to put Controller classes in subdirectories within the Controllers directory. My questions are:
Is this even an option? I can't seem to find any examples with
this approach
How do I register the Controllers that are in the
subdirectories such that when I add routes in the RouteConfig.cs
file, they leverage the controller that is in a subdirectory?
Thank you!

Is this an option? Definitely. You can place the controllers wherever you want. MVC would automatically scan the assembly for controllers and it doesn't matter if they are placed only under Controllers.
If things get more complex, and you want better organization, you can leverage the concept of Areas in ASP.NET MVC - http://msdn.microsoft.com/en-us/library/ee671793(v=vs.100).aspx

ASP.NET MVC2 Routing / Folder structure

In ASP.NET MVC2,
How do I change routing/folder structure so I can have
Views\FOLDER\Account\ChangePass.aspx
Rather than:
Views\Account\ChangePass.aspx
I don't actually want to do it for the account, but I'd like to structure things like that, e.g.
SO I can have two different views like:
Views\Categories\
Views\Admin\Categories\
These would display completely differently.
All I want to do is to be able to create my own subfolders to push the views into, not a seperate folder for each different controller...............................................................

Sounds to me like you need to look into using areas... Have a look at this article for more info:
Walkthrough: Organizing an ASP.NET MVC Application using Areas
Excerpt:
However, some applications can have a large number of controllers, and each controller can be associated with several views. For these types of applications, the default ASP.NET MVC project structure can become unwieldy.
To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).
HTHs,
Charles

Go with the asp.net MVC convention for view location; if you want to have different url paths you need to look at creating your own routes, other than the default single route given to you. (See this primer.)
Here's an example of a route that you might add in your Global.asax to have the desired result but you'll have to map this route to a controller action appropriately. Really, your need to decide on the pattern to meet the need of your app...
routes.MapRoute(
"FolderRoute",
"{controller}/{folder}/{action}/{id}",
new { controller = "Home", folder = "yourFolderDefault", action = "Index", id = "" }
);