I'm trying to migrate an existing WCF web API (targeting the .NET Framework 4.6.1) to ASP.Net Core 2 using Visual Studio 2017 (v15.4.5), and I am having trouble figuring out good / general / supported ways to organize projects and what kind of projects they should be.
For instance:
A single project for server and hosting, or Class Library for server and console for hosting
A Windows Classic Desktop project for a console application and (a new csproj style) web application for a server library, or both web applications (one of which displays a class library, and the other a console application)
I have a hidden suspicion that there is something fundamental that I am missing, which means that one approach must be approved by others or even required, but it was difficult for him to detect this from the ASP.Net Core 2 Documentation .
Specific requirements
Should target .NET Framework 4.6.1
Since I need to access the Windows registry from the internal web APIs, I am targeting the .NET Framework 4.6.1, not the .NET Core.
A host using HTTP.sys
I intend to use Windows Authentication in the future and believe that Kestrel will not support this (based on the HTTP.sys function ).
The host should work as a Windows service
Ultimately, the web API must be installed by the Windows installer and run as a service.
At the moment, I'm just trying to get the API to build / work normally autonomously, but I would also like to get an idea of how the choice of projects can affect publication / deployment.
Preferred Solution
Although by default the new ASP.NET Core 2 web application is a single project that displays a console application, I would prefer to break the solution into two main projects:
- Server - ASP.NET Core 2 (.NET Framework) Class library containing the business logic of the web API, controllers, and startup class
- "Host" is a console application that refers to the "Server" and is responsible for hosting the web API
This scheme seems appropriate to me, since any module / integral testing projects can refer to the Server class library and not to the executable file (according to the recommendation Is it a bad practice to link an exe file in a C # project ).
In addition, I am convinced that this is reasonable, because I can change the output type to "Class Library" in the project properties.
I assume that since I am targeting the .Net Framework, while I am installing the same NuGet packages as the Server project, there is no reason why the Host project cannot be a Windows Classic Desktop Console Application.
Are there any hidden issues, possibly related to publishing / deployment, that make this scheme a bad idea? Would there be any advantage in making the hosting project a web application (which would still reference the server project)?
Attempt
Here are the steps that I used to try to achieve my preferred project organization. While it works, I get warnings generated during the build - see below.
Server
Add new project "Server"
Select Visual C #, Web, ASP.NET Base Web Application
In the next dialog box, specify the .NET Framework, ASP.NET Core 2.0, and select the Web API
- Change the type of output in the project properties to "Class Library"
- Delete Program.cs
Host
- Add new project "Host"
- Select Visual C #, Windows Classic Desktop, Console Application (.NET Framework)
Replace the contents of the program Program.cs:
using Microsoft.AspNetCore.Hosting; using Microsoft.Extensions.Logging; using Server; namespace Host { internal class Program { private static void Main(string[] args) { BuildWebHost(args).Run(); } private static IWebHost BuildWebHost(string[] args) => new WebHostBuilder() .UseStartup<Startup>() .UseHttpSys(options => { options.UrlPrefixes.Add("http://localhost:8080/"); }) .ConfigureLogging((hostingContext, logging) => { logging.AddConsole(); logging.AddDebug(); }) .Build(); } }
Add a link to the server project
- Install these NuGet packages
Microsoft.AspNetCore (2.0.1)Microsoft.AspNetCore.Mvc (2.0.1)Microsoft.AspNetCore.Server.HttpSys (2.0.2)
- Set as launch project
Problem: assembly generates warnings
This solution works under debugging and correctly answers http://localhost:8080/api/values and http://localhost:8080/api/values/1 , but after creating the solution the following warnings are displayed:
Warning The referenced component 'System.Security.Cryptography.Encoding' could not be found. Host Warning The referenced component 'System.Xml.XPath' could not be found. Host Warning The referenced component 'System.IO.FileSystem.Primitives' could not be found. Host Warning The referenced component 'System.IO.FileSystem' could not be found. Host Warning The referenced component 'System.Diagnostics.StackTrace' could not be found. Host Warning The referenced component 'System.Xml.XmlDocument' could not be found. Host Warning The referenced component 'System.Security.Cryptography.X509Certificates' could not be found. Host Warning The referenced component 'System.Diagnostics.FileVersionInfo' could not be found. Host Warning The referenced component 'System.Security.Cryptography.Algorithms' could not be found. Host Warning The referenced component 'System.Xml.ReaderWriter' could not be found. Host Warning The referenced component 'System.Security.Cryptography.Primitives' could not be found. Host Warning The referenced component 'System.ValueTuple' could not be found. Host Warning The referenced component 'System.Xml.XPath.XDocument' could not be found. Host Warning The referenced component 'System.IO.Compression' could not be found. Host Warning The referenced component 'System.AppContext' could not be found. Host Warning The referenced component 'System.Threading.Thread' could not be found. Host Warning The referenced component 'System.Console' could not be found. Host
If this is a reasonable arrangement of projects, why am I receiving these warnings?