We Keep Coding

How to do ASP.NET Core controllers avaiable using Screaming Architecture Conventions?

I'm trying to understand how to do an Asp.Net Core application (3.0) looks like a Screaming Architecture folders and files conventions.
I read about it but and started with an empty project. The folders are:
Controllers
Views
Models
I want to make the web application working like
Customers/Controllers
Customers/Views
Customers/Models
Is it possible?
Thanks in advance.

Both controllers and models are referenced by namespace, so their physical file locations have no bearing on anything. Controllers are dynamically loaded regardless of where they are in the project or even if they're in the project at all (i.e. a controller from a referenced library will automatically be loaded). Models are entirely code-based, and you'd just add a using statement with the namespace of the model(s) to access them in any other piece of code.
Views, however, are very much based on the filesystem, and changing the main folder they're in from just Views or Pages directly in the project root will cause the convention-based view loading to fail completely. You can always add additional view search locations, such that it will look in /Foo/Views and /Bar/Views, etc. but that's really not recommended.
All that said, though, there is a concept of areas, and you can break down your controllers, models, and views that way. You'd simply have to have:
Areas/Customers/Controllers
Areas/Customers/Views
Areas/Customers/Models
In other words, the Areas prefix would be mandatory.

Is this an appropriate way to start sharing code across mutliple mvc apps?

We are developing multiple applications for the same company.
The applications are distinct (so not suitable for a multi-tennant app) but there will be lots of shared models, a couple of shared controllers and ideally some shared views.
It is the first time I have had to do this, and wonder if I am approaching it correctly. Here is my plan:
Create a DB for the shared stuff, and another (per application) for application specific stuff
Each application will have 2 connections in web config
Create a DLL from the shared models and controllers. Put this in the /bin directory and reference it in the project. I want this to approximate the way a nuget package might work, and reference the
For each app create a SharedApplicationDBContext and a LocalApplicationDBContext, each accessing the respective DB.
Questions
Are the above steps the right ones to be taking?
Is there any way to include cshtml Views in a DLL?
Is it ok to include the Users controller / models in the DLL?
Are there any gotchas I should be aware of when sharing code like this over mutliple apps?
I know SO likes specific questions, and this is a bit vague, but I'm a bit out of my depth here and looking for some general guidance as to the right approach to take.

You've got the general idea, but it needs some tweaking:
Don't fool around with DLLs. If the projects exist in the same solution, then you might as well keep your class library there as well. In which case, you can just do a straight project reference. If you're dealing with multiple solutions then you package your class library as a nuget package and actually install it in each project. Creating a nuget package is easy enough, and you can either install from a local/network path or you can set up your own private nuget repo. This makes it stupidly easy to share resources, and you get the ability to publish updates and see at a glance which projects are running which versions of your class library.
Each app should only have the context that relates to its individual database. The shared database can also use a shared context, which would be contained in your class library. You should also house all your migrations related to this shared context in the same class library.
You can include views in a class library, but not as cshtml. They have to be compiled into the class library. You'll need RazorGenerator to accomplish this.
It's 100% okay to include the models related to users in your shared library. However, the controller is trickier. Unless you set up an SSO server that will alone be responsible for handling all authentication (a non-trivial task to say the least), each application will need it's own controller for authentication tasks. If all of the sites will reside on the same domain or subdomains thereof, you can easily share the auth cookie between them. However, if they will reside on entirely different domains, you can still share the same "users", by virtue of using the same database for each, but each site will require a separate login process (logging in at one does not log you in at another, even though the same credentials would work for both). The only way around that is, again, SSO.

For what concerns the views, you can include them in a DLL, please read here
For the models it's ok to have them in a different project.
For the controllers you can do it but you must let MVC know where the controllers will be located and you can do it by writing a custom ControllerFactory, please read more here.

structure for applying Identity on a multi-project solution

I've been working on a Web API solution that's separated on various projects, one of each is the API itself which contains the controllers and Views but all the Business Logic is done in all the other projects (being one of them responsible for all database iteration).
Now I want to apply Authentication using Identity which I wasn't familiar with but was able to understand a lot better thanks to this series of articles and so was able to get it to work on a test solution.
My question here is, how should I organize the different parts of the Identity implementation? Should I...
Make everything directly on the API project?
Create a separate project for all the Identity Implementation except for the controllers?
Use it some other way that you will suggest?
*If you suggest using different project, will I be able to pass the owin context between the projects? how?

Multiple MVC projects in a single solution

I have seen in NopCommerce project that there is a solution and there are multiple MVC projects within the solution.
I have some questions about it such as :
How is it possible to share a main layout, or use different layout on demand?
How is it possible to use Controllers/Models etc. in different MVC projects?
I would also like one main project and multiple sub MVC projects. How can this be done while sharing components?
Any ideas? pointers?
Note: Not interested in Areas.

Yes it is. See: asp.net mvc put controllers into a separate project
I've done this myself and was able to use the controllers in a plug-in type architecture.
As for the models, they are just normal classes. They can be used in any project for any reason. There is nothing special about them.

Grouping Views, Controllers, Models in MVC

maybe i am wrong but i seriously i don't like the current structure of MVC application, and i think on big projects it will cause trouble to maintain.
so is there a way to group related Controllers,Views, Models together, like if i have gallery Module i want all it's Controllers, Views, Models to be grouped under Gallery Folder.

Areas sound like what you are looking for. This will let you group controllers/views/etc. Unless I misunderstood the question?

Phil Haack discussed this here, it's the same issue I've faced and have yet to overcome correctly.

From the sound of it you're moving against the basic principals of MVC, that being the separation of Model, View and Controller rather than your desire to split at 90 degrees to that by using modules.
I'm not entirely sure what benefit you would get from splitting it in to modules any way since I would expect you to have one GalleryController. Where you are likely to have the most 'entities' needing grouping is with the views, possibly one or more for each GalleryController action, but they are in their own folder which gives the sort of functionality you are looking for anyway.
Finally there are the models. Obviously I don't know your project so I don't know how it is laid out, but the Models do not usually exist for the use of one Controller (or module in your case). For example - I have Models for Users, Companies, Vehicles, etc, etc. These models are a shared representation of my data structure and have nothing to do with modules as a user may see it looking at a web page. I can't split them in to modules because the whole point is that they are shared by the entire application.
So...in reality it is the Views which can get a bit messy, but they are already split in to folders based on their Controller. Having said that you can move them around a bit if that suits your needs better. For the rest of it there is no need, either because you shouldn't if you want to use 'proper' MVC (i.e. modular Models) or there's no need (i.e. only one Controller). And if your controller gets too big just create a separate module for any functionality in that you want to split out. I reckon that's as modular as you should ever need to get.

I found a relatively simple solution that uses IIS configuration to simulate areas. No extensions to the existing MVC framework are needed.
Create a new MVC project under your solution for each area you want in your site (ex. Root, Blog, Forum, App1, App2). If you need any common supporting code or a common model, put it in a seperate dll project that the MVC projects depend on.
In IIS, configure the site root to point at the root project directory. Create web applications under the site root that point to each of the sub-area project directories.
When configuring the route maps for each sub area, don't include the name of the application in the route. IIS seems to take care of this for you. (ex. "ShowPost/{postname}", not "/Blog/ShowPost/{postname}")
The benefit is that you can change the name of the web applications independent of the routing system, and each application believes it is running with the whole server to itself.