Develop Reference

How to create models in .NET 5 Web API using EF Core DB first approach

I am working on .NET 5 Web API in which I have several projects in one solution. One project is for only controllers, another one I have added as class library project for interfaces, third project is also class library project for models which I would need to create it from existing DB using EF core. Fourth project is again class library project where I will write data manipulation logic using EF core. As most of the online tutorials are using Code first approach so I am little bit stuck for my DB first approach. Since I am doing this 1st time. I have few questions.
Are these projects structures right? If not please suggest ideal enterprise level solution design structure.
I have added EF core related nuget packages in 3rd an 4th project. Now I want to create entities from existing DB tables. How I can create it to particular project. I am running a below command
Scaffold-DbContext "Server=.;Database=BookStore;Trusted_Connection=True;"
Microsoft.EntityFrameworkCore.SqlServer
Its creating context classes in API project instead of DTO project. How can I create models in DTO project.
I have few tables now. Going forward we will add new table, SPs in DB as per requirements. In that case how to refresh models without disturbing existing models and validations logic written for it.

Open the Package manager console and select DTO from the dropdown. Run the following command. Make sure your directory must be there to import models into
Scaffold-DbContext
"Server=.;Database=PalletPal_LicenseStore;Trusted_Connection=True;"
Microsoft.EntityFrameworkCore.SqlServer -OutputDir YourModelDirectory
-Force

VS Solution Configuration for Web API / MVC

I've been working in ASP.Net WebForms for the last 10 years and am trying to move myself into some more current technologies. I therefore am just doing a small Todo list project with the following outcomes.
Setup a central SQL DB
Create an ASP.Net Core Web API project to handle data requests
Have a ASP.Net Core MVC project that has a web interface
Create a PWA application to install on both iOS and Android
I have completed steps 1 and 2. I have got to step 3 and not sure how to configure the MVC app. I have a few questions around how I should set this up.
Please note that I have setup the Web API project with .Net Core 3.1 and have used Entity Framework and so therefore have a DB Context.
Should I house the MVC project in the same solution as the Web API project.
If I do house the MVC project in the same solution should I be calling the DBContext directly (c# not javascript) from the WebAPI (setup as a reference) or should I be calling the Web API controllers directly?
If I do house the MVC project and the web API project in the same solution - when I go to deploy this real world will I be able to separate the 2 projects as different hosts so that my WPA can get to the Web API.
Should I have the MVC project completetly seperated and consume the WebAPI project as an external project.
Thanks
2.

This can be organized in many ways. I can tell you how I would proceed.
(Assuming you are moving to .net core world).
I will try to describe how to organize your solution in separate projects, and I will assume you want to use entity-framework, repository and unit of work patterns for DB access.
I would create the following projects in my solution:
one .NET Standard project to hold only models (entities and DTO's) - name it "YourNamespace.Models"
one .NET Standard project to hold repository and unit of work contracts/interfaces - name it "YourNamespace.Contracts"
one .NET Standard project to be your data access layer - name it "YourNamespace.DAL". This is where you install EF Core, where you would have your entities configurations (if using Fluent API), your migrations would be here also (if needed), your repositories implementations, as well as the unit of work and database context.
one .NET Standard project for your services - name it "YourNamespace.Services"
one API project for your API controllers/REST services - name it "YourNamespace.TodoAPI"
one MVC project for MVC controllers - name it "YourNamespace.TodoMVC"
This structure is nice for using dependency injection for your services and anything else you need.
Make sure to select the Multiple Startup Projects option under Set StartUp Projects (right-click on your solution).
Select both API and MVC as startup projects.
Something similar is described here

Asp.net Core MVC - Unit testing Razor Views

I am trying to write UI unit tests for my MVC core project and my problem is I am not able to find a MVC view generator or renderer that I can use in my unit test project.
I did implement a ViewRenderService for a specific requirement in another project but I cannot use it because of the dependencies cannot be injected into the unit test project.
What is a better way to approach this for dotnet core mvc? Any guidance will help.

.NET Core project dependency "bleed"

Reference encapsulation in .NET Core seems to have changed in a way which allows references in one project to "bleed" into another project.
In prior versions of .NET, assemblies referenced by project "X" were not exposed to other projects in the solution which referenced project "X".
So for example, if you had a Domain project which referenced Entity Framework, adding a reference to that Domain project to another project in your solution would not grant that other project access to any Entity Framework classes.
This was a good thing (at least in my opinion).
Was playing around with a .NET Core 2.1 app tonight, and created a domain project
which leveraged EF Core.
I then created a unit test project (in eager anticipation of leveraging the new EF Core InMemory provider), and referenced my domain project.
What completely caught me off guard was that the unit test project was able to access EF Core classes even though I did not bring the EF Core NuGet package into the unit test project; my only assumption is that it was able to access EF via my domain project, ie:
This seems highly undesirable; I don't care too much about reference bleeds in my unit tests, but I do care very much about this kind reference bleed when working with other projects in my solution (such as an ASP.NET Core Web project).
Is there a way to hide / shield these package references in my Domain project from other projects which reference it?

This is a curious thing and i have never noticed it before,
However take a look at this
Controlling dependency assets
PrivateAssets These assets will be consumed but won't flow to the
parent project
And the tag
compile Contents of the lib folder and controls whether your project
can compile against the assemblies within the folder
Right click Class library -> Dependencies -> Nuget -> Package, and set the PrivateAssets to the word compile... I was seemingly able to use (and yet hide the dependency) in a calling .Net Core project.
Disclaimer, i really only played with this setting out of curiosity, and not really sure if there are any side affects to doing this

Suggested setup for OS project with several NuGet packages

I decided to share a small project I have been working on for a while. It's basically a development framework for distributed applications.
Now I'm setting up the GitHub repository and I wanted to use AppVeyor for continuous integration and I'm struggling with the setup.
As for now, my framework is composed of few packages
Interfaces: defines the basic interfaces, extracted as a package so that you don't need to bring the whole framework in your business logic library
Core: contains the basic components of the framework
CastleWindsor: contains support for the Castle IoC container
RabbitMQ: contains the implementation of the engine based on RabbitMQ
Now, it's pretty easy to setup AppVeyor to build and push into Nuget a single project/package.
But what I'm looking is:
build everything on push (includes testing)
create packages and publish them only on a specific action.
I'm wondering if I should create multiple repositories (one for each package) on GitHub and have multiple projects on AppVeyor as well. Or maybe a single repository with multiple projects.
Thanks for your insights.