.NET Core 2.1 and EF Framework 2.1

Question

I'm trying to replace a web service that provides information to a mobile app via ODATA 4. The current application is using EF6 and works without error.

I have subsequently built a NEW .NET Core 2.1.1, using EF 2.1 and Core Odata 7.0.1. Everything seems to be functioning property when run on IISExpress through the Visual Studio 2017 interface.

DEPLOYMENT Issue ?:

The trouble appears to be in deployment to an IIS Server. I have all the correct runtimes and hosting packages installed. Other .NET Core 2.1 using EF 2.1 applications (web pages, not services) run without issue. This service however will launch the $metadata page, and will properly launch the initial interface page. Once I call any controller that has an EF connection I only receive a partial page... There is no errors in the event logs The only "EVENT" I actually receive is an "Information" entry in the "Windows Application Log" of the host IIS Server That says;

Source: MSSQLSERVER Event ID: 18456

Login failed for user 'Domain\\Server16$'. Reason: Could not find a login matching the name provided. [CLIENT: 192.168.1.16]

The SQL connection string is in the appsettings.json file, and this connection string works within visual studio itself... All of this occurs after deploying to an actual IIS Server, and only with this web service, not other applications that use EF 2.1.

Is there something I have missed in development? Is this a known issue? Anyone have a clue?

Solution: (sort of)

I am fully aware that IIS is a "proxy" front end for the Kestrel server that runs the .NET Core application. That said, you would think that the application identity pool for IIS (the host) would be irrelevant since the .NET Core application should be "fully self-contained". Well... No... In fact, if you leave AppPoolIdentity (the default), like you did for all previous ASP.NET MVC applications and then created connection strings inside appsettings.json files for security reasons, well this doesn't work, because there is a glaring flaw (IMHO)… In my use case, Web Service running on a SQL Server back-end, you will need to give the PROXY, in this case the IIS AppPool running your service access to the same database. So, now I have to have two accounts gaining access to backend services... This seems short sited in a security conscious world!

https://weblog.west-wind.com/posts/2016/Jun/06/Publishing-and-Running-ASPNET-Core-Applications-with-IIS

Answer 1

Despite the short-sited nature of .NET Core applications being hosted by IIS as a proxy front end, it appears that the AppPool running the IIS Proxy requires access to the same database server that the SQL Account used for the database requires... YUCK!

Thanks to Edward (who posted a comment), it led me to this post:

https://weblog.west-wind.com/posts/2016/Jun/06/Publishing-and-Running-ASPNET-Core-Applications-with-IIS