能否将MS Teams应用与现有ASP.NET Core Web应用整合到同一项目

该实现思路完全可行，不需要为Teams功能单独搭建独立站点，和现有ASP.NET Core应用合并部署是成熟可落地的方案，维护成本远低于拆分独立站点。

• 资源与路由隔离
  你可以为所有Teams相关功能统一配置独立路由前缀，例如/teams/*：如果用MVC/Razor Pages技术栈，可以单独为Teams模块划分Area，把专属视图、静态资源（Teams定制脚本、样式、交互控件）放到独立目录下；如果要集成官方Blazor示例的能力，也可以把Teams相关Blazor组件放到独立文件夹，或者封装成内部Razor类库引用，和原有业务代码完全区隔，不会产生资源冲突。
• 认证逻辑并行兼容
  不需要改动你现有的ASP.NET Identity用户名密码认证、IdP发起SSO、多租户逻辑，只需要针对Teams专属路由分支配置独立的认证管道：
  • 用路由分支映射的方式，只对/teams路径下的请求注册Teams SSO令牌校验、身份解析中间件，不影响原有站点的认证流程
  • 给API层配置多认证Scheme支持，同时接受原有业务令牌、Teams SSO令牌，直接复用现有API的业务逻辑，只需要按访问来源补充权限判断即可
  • 多租户解析逻辑可以直接复用现有能力，只需要在Teams身份校验环节补充租户ID和你现有租户体系的映射规则
• 部署与配置适配
  完全不需要调整现有IIS部署结构，只需要在Teams开发者门户配置应用地址时，把选项卡、消息扩展、Bot消息端点等地址指向你现有站点对应/teams前缀的路径即可。注意只需要针对/teams路径配置对应的CSP响应规则，允许Teams域名以IFrame形式嵌入内容、配置必要的跨域规则，不要全局放开站点安全策略，避免影响原有站点的安全性。

不要把Teams专属的中间件、认证规则全局注册，使用分支管道的方式做逻辑隔离即可，参考代码结构：

app.MapWhen(
    context => context.Request.Path.StartsWithSegments("/teams"),
    teamsAppBuilder =>
    {
        // 这里注册Teams专属的认证、中间件、端点映射逻辑
        teamsAppBuilder.UseAuthentication();
        teamsAppBuilder.UseAuthorization();
        teamsAppBuilder.MapControllers();
        // 其他Teams专属配置
    });
// 原有站点的中间件、路由注册逻辑保持不变

内容的提问来源于stack exchange，提问作者user2058413