我正在尝试替换一个通过ODATA 4向移动应用提供信息的网络服务。当前应用程序使用EF6，没有错误。
随后，我构建了一个新的.NET Core 2.1.1，使用EF 2.1和Core Odata 7.0.1。当在Visual Studio 2017界面上通过IISExpress运行时，一切似乎都能正常运行。
部署问题？：
问题似乎出现在将其部署到IIS服务器上。我已经安装了所有正确的运行时和托管包。其他使用EF 2.1的.NET Core 2.1应用程序（网页而非服务）也能够正常运行。然而，该服务只会启动$metadata页面，并且会正确启动初始接口页面。一旦调用任何具有EF连接的控制器，我只收到部分页面……事件日志中没有错误，我实际上只收到主机IIS服务器的“Windows应用程序日志”中的“信息”条目，其中说：
来源：MSSQLSERVER 事件ID：18456
用户'Domain\Server16$'的登录失败。原因：找不到与提供的名称匹配的登录。[客户端：192.168.1.16]
SQL连接字符串在appsettings.json文件中，这个连接字符串在Visual Studio本身中有效...所有这些都发生在部署到实际的IIS服务器之后，并且仅适用于此Web服务，而不适用于使用EF 2.1的其他应用程序。
在开发中我有什么遗漏吗？这是一个已知问题吗？有人有线索吗？
解决方案：（有点）
我完全意识到IIS是运行.NET Core应用程序的Kestrel服务器的“代理”前端。也就是说，你会认为IIS（主机）的应用程序标识池是无关紧要的，因为.NET Core应用程序应该是“完全自包含”的。嗯...不是...事实上，如果像以前的所有ASP.NET MVC应用程序一样保留AppPoolIdentity（默认值），然后在appsettings.json文件中创建连接字符串以提高安全性，那么这将不起作用，因为有一个明显的缺陷（依我看）...在我的用例中，Web服务运行在 SQL Server 后端，您需要给代理（在这种情况下是运行服务的IIS AppPool）访问相同数据库的权限。所以，现在我必须有两个帐户获得访问后端服务的权限...在一个注重安全的世界中，这似乎是短视的！
随后，我构建了一个新的.NET Core 2.1.1，使用EF 2.1和Core Odata 7.0.1。当在Visual Studio 2017界面上通过IISExpress运行时，一切似乎都能正常运行。
部署问题？：
问题似乎出现在将其部署到IIS服务器上。我已经安装了所有正确的运行时和托管包。其他使用EF 2.1的.NET Core 2.1应用程序（网页而非服务）也能够正常运行。然而，该服务只会启动$metadata页面，并且会正确启动初始接口页面。一旦调用任何具有EF连接的控制器，我只收到部分页面……事件日志中没有错误，我实际上只收到主机IIS服务器的“Windows应用程序日志”中的“信息”条目，其中说：
来源：MSSQLSERVER 事件ID：18456
用户'Domain\Server16$'的登录失败。原因：找不到与提供的名称匹配的登录。[客户端：192.168.1.16]
SQL连接字符串在appsettings.json文件中，这个连接字符串在Visual Studio本身中有效...所有这些都发生在部署到实际的IIS服务器之后，并且仅适用于此Web服务，而不适用于使用EF 2.1的其他应用程序。
在开发中我有什么遗漏吗？这是一个已知问题吗？有人有线索吗？
解决方案：（有点）
我完全意识到IIS是运行.NET Core应用程序的Kestrel服务器的“代理”前端。也就是说，你会认为IIS（主机）的应用程序标识池是无关紧要的，因为.NET Core应用程序应该是“完全自包含”的。嗯...不是...事实上，如果像以前的所有ASP.NET MVC应用程序一样保留AppPoolIdentity（默认值），然后在appsettings.json文件中创建连接字符串以提高安全性，那么这将不起作用，因为有一个明显的缺陷（依我看）...在我的用例中，Web服务运行在 SQL Server 后端，您需要给代理（在这种情况下是运行服务的IIS AppPool）访问相同数据库的权限。所以，现在我必须有两个帐户获得访问后端服务的权限...在一个注重安全的世界中，这似乎是短视的！
DbContext相关的Startup.cs代码。通常，如果您指定了User ID和Password，则无需在用户帐户标识下运行 Core 应用程序。对于 **Login failed for user 'Domain\Server16$'**，似乎您正在使用Server16$进行登录。请分享您的appsettings。 - Edward