了解 Microsoft 身份命名空间（System.Web.Security、Microsoft.AspNet.Identity.Core 与 Microsoft.AspNetCore.Identity）
Understanding Microsoft Identity Namespaces (System.Web.Security, Microsoft.AspNet.Identity.Core, vs Microsoft.AspNetCore.Identity)
希望有人遇到过类似的问题，可以给点建议。我研究了一段时间，但找不到确定的答案。
我的设置：
- 1 MsSQL 数据库（包含 System.Web.Security 的标识表）
- .Net Framework 中的许多 DLL（使用 System.Web.Security 登录）
- 多个不同的 Programs/Apps 调用 DLL
- .Net Framework 中的 WebForms GUI（使用 System.Web.Security 登录）
我想要的：
- 在 .net Core 或 .Net Framework 中使用 IdentityServer4
- 在 .Net Framework 中保留 DLL
- 在 .Net Core 中使用 WebApi
- 使用新的 GUI（f.ex。在 Angular 或 Blazor 中）
- 在新 GUI 的同时使用 WebForms 中的旧 GUI（直到新 GUI 完成）
我的问题：
我的 DLL 和应用程序使用 System.Web.Security 进行用户管理（登录等）。 .Net Core 不支持此命名空间，但将我所有的 DLL 更改为 .Net Core 对我来说是不可行的，因为这会导致太多更改。我想将它们保存在 .NetFramework 中。
我的主要问题之一：
- .Net Core (f.ex.WebApi, IdentityServer4) 中的应用程序和 .NetFramework 中的 App/Dlls 是否可以使用相同的身份数据库（登录、会员资格等）。换句话说，如果在不同的 Apps/Dlls 中使用，"microsoft.aspnet.identity" 和 "microsoft.aspnetcore.identity" 兼容（关于数据库）。
- 或者我是否必须使用所有 apps/dlls 中的身份命名空间之一才能兼容？ （因此必须在所有 apps/dlls 中使用相同的框架）
我希望这足够简短清楚地描述我的问题。如果有什么不清楚的地方，请告诉我。
更新
我刚发现 Post 也许在所有 DLL 中使用 .Net 标准可能是一种选择。我会试试这个，看看它会适合我。但我仍然不明白 "microsoft.aspnet.identity" 和 "microsoft.aspnetcore.identity" 是否以及如何在 .Net 标准库中工作。
结果：我能够使用 "Microsoft.AspNetCore.Identity"，
"Microsoft.EntityFrameworkCore" 在 .Net Standard 2.1 库中（Microsoft.EntityFrameworkCore 在 .Net Standard 2.1 和 net Core 3.0 中受支持）。所以这是个好消息（我不必为了身份而将所有 DLL 迁移到 .Net Core。迁移到 .Net 标准就足够了）。
但是我无法在 .Net Framework 中引用 .Net Standard 2.1 DLL DLL/App 因为 .Net Framework 最高支持 .Net Standard 2.0...没有完全解决问题，但它似乎是最接近我想做的事情。
更新2
我准备为这次改动改很多代码。 F.ex。旧 WebApp 中的身份验证，以便它与 IdentityServer 对话并删除所有项目中与 System.Web(.Security) 相关的所有内容。
仍然让我感到困惑的一件事是 "microsoft.aspnet.identity" 与 "microsoft.aspnetcore.identity"。我是否必须为所有项目选择其中之一，或者我可以混合这些名称空间（取决于项目的框架）但只保留一个数据库。
更新3
我标记了一个答案，因为它有助于回答我的基本问题 ("it's not possible")。我将尝试实施它并看到它出现更多问题。
但是如果有人有更多关于这个主题的ideas/experiences，请随时在这里分享。
我使用的一些来源：
- 没有计划将 System.Web.Security 移植到 .Net Core：https://github.com/dotnet/core/issues/838
- 数据库中的身份表从 2012 年到 2013 年发生了变化：What's the diff between dbo.aspnet_Users and dbo.aspnetUsers?
- 关于会员提供程序与 aspnet .core 不兼容的讨论：https://github.com/aspnet/AspNetCore/issues/1501
- 包含大量信息的有关迁移的视频：https://www.youtube.com/watch?v=shn3gL_UJ38
- 关于 Identity 和 .Net 的讨论 Core/Standard 与我的问题类似（但没有帮助，可能遗漏了什么）：
- 将 .Net 迁移到 .Net Core 的指南：https://docs.microsoft.com/en-us/aspnet/core/migration/proper-to-2x/?view=aspnetcore-2.1
- "Microsoft.AspNet.Identity.Core" 对比 "Microsoft.AspNetCore.Identity"：
- IdentityServer4 也可以在 .NetFramework 中（不必是 .Net Core）https://leastprivilege.com/2017/01/15/platforms-where-you-can-run-identityserver4/
谢谢！
尽管名称中都有 ASP.NET，但 ASP.NET Core 是一个与 ASP.NET 完全不同的框架。人们似乎没有意识到这不仅仅是版本跳跃：您将必须重写您的应用程序。
ASP.NET 成员资格 (System.Web.Security) 已弃用，.NET Core 中 100% 不受支持。这不会改变，这里没有解决方法。如果您想在 ASP.NET Core 中进行身份验证，则必须从头开始。
既然你想使用 Identity Server，无论如何，你仍然可以支持你的遗留 Web Forms 应用程序，但你必须将所有身份验证移动到 Identity Server，然后使用 Identity Server 作为 Web 中的身份验证机制表格应用程序。同样，这将要求 对 Web 窗体应用程序进行更改。这里没有其他选择。
在身份服务器端，您可以选择放弃 ASP.NET 身份。身份服务器只是身份验证提供者；它不关心用户管理。从技术上讲，您可以继续使用旧的用户表，但您必须为 Identity Server 创建自定义配置文件和用户存储提供程序，以使其能够完成需要完成的工作。老实说，你最好从这里开始使用身份，而不是做大量的工作来尝试支持一个很久以前就被弃用的用户管理系统。
总而言之，这里没有什么是微不足道的。如果您想做您正在谈论的事情，那么您正在着手进行一项 重大 项目，这将需要大量的努力并改变您应用程序的每一部分。就是那样子。如果你还没有为此做好准备，那就坚持你所拥有的。
希望有人遇到过类似的问题，可以给点建议。我研究了一段时间，但找不到确定的答案。
我的设置：
- 1 MsSQL 数据库（包含 System.Web.Security 的标识表）
- .Net Framework 中的许多 DLL（使用 System.Web.Security 登录）
- 多个不同的 Programs/Apps 调用 DLL
- .Net Framework 中的 WebForms GUI（使用 System.Web.Security 登录）
我想要的：
- 在 .net Core 或 .Net Framework 中使用 IdentityServer4
- 在 .Net Framework 中保留 DLL
- 在 .Net Core 中使用 WebApi
- 使用新的 GUI（f.ex。在 Angular 或 Blazor 中）
- 在新 GUI 的同时使用 WebForms 中的旧 GUI（直到新 GUI 完成）
我的问题： 我的 DLL 和应用程序使用 System.Web.Security 进行用户管理（登录等）。 .Net Core 不支持此命名空间，但将我所有的 DLL 更改为 .Net Core 对我来说是不可行的，因为这会导致太多更改。我想将它们保存在 .NetFramework 中。
我的主要问题之一：
- .Net Core (f.ex.WebApi, IdentityServer4) 中的应用程序和 .NetFramework 中的 App/Dlls 是否可以使用相同的身份数据库（登录、会员资格等）。换句话说，如果在不同的 Apps/Dlls 中使用，"microsoft.aspnet.identity" 和 "microsoft.aspnetcore.identity" 兼容（关于数据库）。
- 或者我是否必须使用所有 apps/dlls 中的身份命名空间之一才能兼容？ （因此必须在所有 apps/dlls 中使用相同的框架）
我希望这足够简短清楚地描述我的问题。如果有什么不清楚的地方，请告诉我。
更新
我刚发现 Post
结果：我能够使用 "Microsoft.AspNetCore.Identity"， "Microsoft.EntityFrameworkCore" 在 .Net Standard 2.1 库中（Microsoft.EntityFrameworkCore 在 .Net Standard 2.1 和 net Core 3.0 中受支持）。所以这是个好消息（我不必为了身份而将所有 DLL 迁移到 .Net Core。迁移到 .Net 标准就足够了）。 但是我无法在 .Net Framework 中引用 .Net Standard 2.1 DLL DLL/App 因为 .Net Framework 最高支持 .Net Standard 2.0...没有完全解决问题，但它似乎是最接近我想做的事情。
更新2
我准备为这次改动改很多代码。 F.ex。旧 WebApp 中的身份验证，以便它与 IdentityServer 对话并删除所有项目中与 System.Web(.Security) 相关的所有内容。 仍然让我感到困惑的一件事是 "microsoft.aspnet.identity" 与 "microsoft.aspnetcore.identity"。我是否必须为所有项目选择其中之一，或者我可以混合这些名称空间（取决于项目的框架）但只保留一个数据库。
更新3 我标记了一个答案，因为它有助于回答我的基本问题 ("it's not possible")。我将尝试实施它并看到它出现更多问题。 但是如果有人有更多关于这个主题的ideas/experiences，请随时在这里分享。
我使用的一些来源：
- 没有计划将 System.Web.Security 移植到 .Net Core：https://github.com/dotnet/core/issues/838
- 数据库中的身份表从 2012 年到 2013 年发生了变化：What's the diff between dbo.aspnet_Users and dbo.aspnetUsers?
- 关于会员提供程序与 aspnet .core 不兼容的讨论：https://github.com/aspnet/AspNetCore/issues/1501
- 包含大量信息的有关迁移的视频：https://www.youtube.com/watch?v=shn3gL_UJ38
- 关于 Identity 和 .Net 的讨论 Core/Standard 与我的问题类似（但没有帮助，可能遗漏了什么）：
- 将 .Net 迁移到 .Net Core 的指南：https://docs.microsoft.com/en-us/aspnet/core/migration/proper-to-2x/?view=aspnetcore-2.1
- "Microsoft.AspNet.Identity.Core" 对比 "Microsoft.AspNetCore.Identity"：
- IdentityServer4 也可以在 .NetFramework 中（不必是 .Net Core）https://leastprivilege.com/2017/01/15/platforms-where-you-can-run-identityserver4/ 谢谢！
尽管名称中都有 ASP.NET，但 ASP.NET Core 是一个与 ASP.NET 完全不同的框架。人们似乎没有意识到这不仅仅是版本跳跃：您将必须重写您的应用程序。
ASP.NET 成员资格 (System.Web.Security) 已弃用，.NET Core 中 100% 不受支持。这不会改变，这里没有解决方法。如果您想在 ASP.NET Core 中进行身份验证，则必须从头开始。
既然你想使用 Identity Server，无论如何，你仍然可以支持你的遗留 Web Forms 应用程序，但你必须将所有身份验证移动到 Identity Server，然后使用 Identity Server 作为 Web 中的身份验证机制表格应用程序。同样，这将要求 对 Web 窗体应用程序进行更改。这里没有其他选择。
在身份服务器端，您可以选择放弃 ASP.NET 身份。身份服务器只是身份验证提供者；它不关心用户管理。从技术上讲，您可以继续使用旧的用户表，但您必须为 Identity Server 创建自定义配置文件和用户存储提供程序，以使其能够完成需要完成的工作。老实说，你最好从这里开始使用身份，而不是做大量的工作来尝试支持一个很久以前就被弃用的用户管理系统。
总而言之，这里没有什么是微不足道的。如果您想做您正在谈论的事情，那么您正在着手进行一项 重大 项目，这将需要大量的努力并改变您应用程序的每一部分。就是那样子。如果你还没有为此做好准备，那就坚持你所拥有的。