Setting Up the Projects for DotNet Core Web Api – Revisited

Before creating any projects we will create a new branch in git locally, then push it up to The following lines of code will accomplish this:

git checkout -b Setup_Projects
git push origin Setup_Projects

After this the local and remote repositories will both have a branch named Setup_Projects.

Create Projects

Now we are ready to create the projects that will comprise our solution. From a high level view this is what it will all look like if opened in Visual Studio:


One thing that might jump out at you is that there is a seemingly superfluous console application. I tend to include such a project to test various thing as I develop. I find it very useful in terms of playing around with what will work, what will not, etc.

Again we will be using the yo scaffolding engine and here are the commands that need to be run from the application root, in the Node.js command prompt, (the CoreWebApiPubs folder):

yo aspnet console PubsConsoleApp --version-current
yo aspnet classlib Pubs.Data --version-current
yo aspnet classlib Pubs.DTO --version-current
yo aspnet classlib Pubs.Repository --version-current
yo aspnet mstest Pubs.Data.Test --version-current
yo aspnet webapi Pubs.Api --version-current
yo aspnet mvc Pubs.Mvc bootstrap --version-current
yo aspnet web Pubs.Web bootstrap --version-current

Notice the –-version-current after each command. This assures that the most recent dotnet core version, 1.1.1 as of this writing, will be used.

One thing to note is that using the standard dotnet core cli calling ‘dotnet new’ will generate the new project in the current folder, whereas the yo aspnet generator will create a folder with the same name as the project name and create it there. That is if you were to create a folder named Pubs.Data, cd into that folder, then run the ‘dotnet new’ you will have a new project in that folder, on the other hand were you to run the command ‘yo aspnet classlibrary Pubs.Data’ you will have a new project in the folder Pubs.Data\Pubs.Data.


You can review the announcement for the 1.1 release of dotnet core here. At the moment things are moving very fast so even though at the time of the release the suggested approach was to use the project.json format they now utilize a .csproj approach. While this gives the same result, and can be edited in the same way, it at the least gives the appearance of pushing us towards Visual Studio, rather than VS Code or some other free and/or non-Microsoft tool as an IDE/Editor. Having said that, if you have projects that you started with a project.json file, that you want to convert to using a .csproj file, the command

dotnet migrate

will accomplish this. Along the same lines

dotnet migrate -h

will provide help regarding the available options. If you want to see a comparison between the two formats, this page provides a reference to the elements of the csproj file, along with translations between the two: project.json and csproj comparison - .NET Core | Microsoft Docs

Data and DTO Projects

NOTE: The purpose of the DTO project is so that the api itself be agnostic as to the type of data being passed back and forth. The Repository project, or the Unit of Work project, if implemented, will handle the transformations.

These two projects are fairly straightforward so it makes sense to me to complete these two, and possibly do some tests on them, in this branch. I will need to run a command on the dotnet cli command line to generate the ef code. For this line to work some changes will be needed to the NuGet packages of the project under which I will be running the command to generate the entity framework code. Again, assuming that this will be done in VS Code there is a good package manager that can handle all this: ‘NuGet Package Manager’ from jmrog. once I get the references into one project the corresponding lines can be copied to another. In the PubsConsoleApp I have added this section:

   <PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final"/> 
   <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.2"/> 
   <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.Design" Version="1.1.2"/>
  <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0"/>

One way to add these references in VS Code is to use the extension ‘NuGet Package Manager’ (jmrog.vscode-nuget-package-manager) which will allow you to add NuGet packages easily. Once the extension in installed just do Shift+Ctrl+P, then type in nuget (Add is the first option), Enter, start typing the package you want to add, select the one you want, then select a version and, finally, the project to which to add the package.

One may add these references to each project which will need the entities, in our case Pubs.Data and Pubs.DTO. The issue is that neither one will need the tools section, or the references to Design, going forward: Pubs.Data will only need the "Microsoft.EntityFrameworkCore.SqlServer" line, and Pubs.DTO will not need any of these. So the choice is whether to add these lines to the .csproj file of each project, then removing what is unnecessary afterwards, or else adding all that is needed to the ConsoleApp project, running the ef code, copy the generated classes and updating the namespaces.

This is the ef line that will need to be run:

dotnet ef DbContext Scaffold "Your connection string here" Microsoft.EntityFrameworkCore.SqlServer --context PubsDbContext --output-dir "Entities" --force --data-annotations

Note: if you get the following message on the command prompt:

No executable found matching command "dotnet-ef"

then most likely you have not set up the csproj file correctly, review the PackageReferences and the DotNetCliToolReference above.

Obviously will need to fill in the values for the connection string that applies to you. Regardless of your approach, the DTO code will not need, or want, the data annotations, or to be put in a separate folder, so those two parameters will need to be removed. Two important points to keep in mind are the following:

  • The DTO project does not need the PubsDbContext class so either remove if generating the code from the DTO project, or else do not copy into the DTO project
  • The PubsDbContext class will contain the connection string and that is a very bad idea to deploy into any environment. To get around this I remove the body of the OnConfiguring method and add a constructor that will take a DbContextOptions object as a parameter: public PubsDbContext(DbContextOptions options) : base(options) { }.

NOTE: the ef generator will not generate any code for the discounts or roysched tables since these do not have primary keys. It will be left as an exercise to the reader to generate on one’s own.

Now is a good time to step back and do any clean up type actions. For one I go into each project to do a restore and build. Then to update the git repositories (local and remote), which is done with these lines of code in a command prompt:

git add .
git commit -m"Initial project creation"
git push origin Setup_Projects

When you do so you will be prompted for your user name and password on github.

Now the Setup_Projects branch of both the local and remote repositories are up to date.

No Comments

Add a Comment