Develop Reference

.NET Clean architecture - multiple projects

I try do my projects with clean architecture. I use Entity Framework. Everything is good and easy to know. I have structure like this - Domain, Application, Infrastructure etc. I create my project without any big problems - WebApi project. Now I would like to add Blazor server side project. What is the right way? Only add Blazor project to my existing solution? Here is few problems for me. I will have the logic of two applications linked (handlers). And I have some nuget packages which contains webapi specializations. When I create own solution for blazor app here is only one problem. The duplicate of dbcontext. I need "duplicate" (I can use only 2 tables if I need) domain project with entites and dbcontext in infrastructure. But then it work's good and it's clear. But I don't think it's good way to duplicate domain project. And where is stored migrations?
I know if projects will microservices it will be super clear and it's makes sense. But when I have monolith and would like WebApi and Blazor app with one database what's right way?

What is the right way?
As always - it depends.
In the Uncle Bob's article on the Clean Architecture the following point is present:
Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
If your Blazor App can be considered just another UI (without major changes to the business rules, though it can have some specific use cases) then it should be a part of the current solution.

I was Studying a course in PluralSight in clean-architecture by Gill Cleeren, they the Blazor project to the same solution

The point of Clean Architecture is that you do not have to duplicate shared logic. Blazor server project is a "front-end" layer at the edge of your application. If implemented correctly you will reference the other projects just like your WebAPI does.
Try to add a Blazor Server project to your solution and reference the Application/Infrastructure/Domain projects that already exist and you should be able to re-use all the exisitng logic.
Blazor (and WebAPI) is nothing more than a way to present your data, so keep it that way.

Multiple solutions application

I'm planning to create a website using ASP.NET Core 2.0 , Entity Framework Core, Angular.
I was planning to create one solution with different projects (core, data layer, UI ...etc ) however the client quoted "this is a bad idea, please create separate solution for your UI and API).
how can i create multiple solution and still let them interact with each others?
What is the best practice?
If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?

Solution is basically just a logical container for projects, so you can create multiple solutions which will reference the same (existing) projects. This is quite common for large solutions like for example Xamarin.Forms - you can have one large solution with all projects and then have smaller solutions for developers who need to work with only a subset of the projects.
You can add existing project to your solution by right-clicking the solution in Solution Explorer and choosing Add - Existing Project.

I think your client may misunderstand what a solution is. Grouping your projects in a solution only affects your workspace in Visual Studio, it does not mean that your projects have dependencies between them (unless you explicitely say so in their references)

The only way I can imagine this working is to deliver each solution as a set of microservices.
However, now your architecture is different. Only one of those solutions is going to be publicly exposed. The others will need to sit behind a firewall to ensure that they can't be reached by external users. But all of them will have scalability and security concerns.
So you'll have a set of data services that encapsulate Entity Framework and expose the data through a Web API, and a business logic API that is reached over a Web API, and then your UI (which should include Angular).
APIs calling APIs. Welcome to microservices.

how can i create multiple solution and still let them interact with each others? What is the best practice? If i create separate solution for my UI, how can i communicate with EF context which is in a different solution?
Answer :
Create base solution first ex : BaseSolution.sln then go to that solution file explorer and create API,UI folder.
Now open visual studio and create new solution ex: ApiSolution.sln save it under API folder and add web api project inside ApiSolution.sln and save.
Now open BaseSolution.sln and right-clicking the solution in Solution Explorer and choosing Add - Existing Project then choose web api project from ApiSolution.sln then add it.
You can follow step 2 and 3 to create more solution and add it to BaseSolution.
Web api connect through HTTPClient with another web api.

Best approach for a large intranet structure with multiple nested applications

So on the current system (running off of the .net 3.5 framework) the way it was made was there is a project for the main intranet site. This page uses a dll to load the menu & layout. Then there are a bunch of separate applications (different solutions) that use this same dll to load the site structure and then get deployed as a new iis site. The menu has links to each of these applications and essentially it creates one large intranet site.
The idea is to recreate the intranet which I have been tasked with. I will be using .net core 2.1 and a mvvm (or mvc) structure. So my question is what is the best way to go about this? I am not totally convinced that the current system uses the best approach and I kinda want to get out of the dll hell that the current system uses (there are lots of dlls not just for the layout). As for the layout and its re-usability what is the best approach for this? Should there be separate solutions for each internal project and how would they reuse the site layout if so? Or should it be one HUGE solution with multiple projects? Or what other approaches could be recommended?

Refactoring code to have multiple web projects or sites in one solution

Context: I have a codebase that consists of an MVC project, WebAPI project and one web project in the same solution that was originally intended to consist of different websites for each of the functions / areas it has, for example within the solution there is a folder for the admin site eg views, service layer, repository etc, and for the customer site there is the same folder structure and files. The code in these two folders do not share the same service layer code and it is duplicated. I want to refactor the code for these two sites into a standard design and layers.
Question: What is the best approach for making these two areas appear as two separate sites in IIS? Currently there is only one site in IIS so it's not possible to have one running without the other. Would I need to make two separate web projects for these, refactor the code and then set the startup projects to multiple startup projects? Because knowing this will directly influence the refactoring of the two areas to use the same service layer logic and shared code.
Any pointers or suggestions on the design for this will be very much appreciated as I have not attempted this before having worked with only one web project within a solution and I would like advice from others who have worked with this type of design and refactoring to make multiple site nodes in IIS for areas/web projects in the same solution.

There's nothing wrong with having 2 or more web projects in a solution and building and deploying separately to IIS. You might have an issue debugging both applications at the same time in the same instance of Visual Studio, but that's easily resolved by opening another Visual Studio!
And this is a great book for looking at different solution layouts.
I've seen some good examples on github in the past too: https://github.com/thiagolunardi/MvcMusicStoreDDD

Share MVC application functionality

I have built and application in ASP.NET MVC, which started out orignally as a way to learn the technology. However, the application (and my knowledge of MVC) have progressed and I would like to use parts of the functionality I have created in other applications. Eg I would have 2 websites both wanting to use the same News Control (CRUD) model and controller methods, but with their own unique Views. I suppose my questions are:
1. Is this going against the principles of MVC?
2. What is the best way to achieve this?
3. Is there a "best practise" way to re-use my exisiting functionality?
Thanks in advance for any answers.

Depending on your exact requirements I'd recommend you take a look at Rob Ashton's series on multi-tenancy in ASP.Net MVC, and also the portable areas part of MVC Contrib.

You could setup a Visual Studio solution in which you would have a common class library project containing models, controllers and data access and two web applications containing only the views and CSS of the two sites both referencing the same controllers and models.

Hopefully most of your logic is already separated out, but you can also pull your controllers out to a separate assembly, I believe:
http://dotnetslackers.com/articles/aspnet/storing-asp-net-mvc-controllers-views-in-separate-assemblies.aspx

Reuse is a really central part to the concept of MVC. It's very common in production MVC sites to have a separate assembly (or assemblies) for the Model. It's somewhat less common (but still done) to do the same for Controllers. The S#harp architecture project (for example) uses a separate assembly for everything, leaving just views, content, and global.asax in the Web assembly. It's all good.
Another thing you might consider is the use of Areas, which are like mini-MVC apps that you can reference in your 'main' app. It's a great way to package reusable pieces like you describe.
Paul