Visual Studio：如何使用 IIS Express 和跨项目引用在共享项目中调试 TypeScript（无链接或复制文件）

Posted 2023-03-07

【中文标题】Visual Studio：如何使用 IIS Express 和跨项目引用在共享项目中调试 TypeScript（无链接或复制文件）

【英文标题】：Visual Studio: How to debug TypeScript in a shared project using IIS Express and cross-project references (no linking or duplicating files)

【发布时间】：2015-03-01 22:23:29

【问题描述】：

理想情况下，我们可以简单地将共享的 TypeScript 项目引用添加到另一个项目，并且能够像使用 Visual Basic 或 C# 跨项目引用一样使用引用的代码。唉，这还不可用。

希望微软将在近期版本中升级 Visual Studio，以便它支持无缝跨项目 TypeScript 调试，而无需复制共享文件。在那之前，我们需要一个解决方法。其他几个人在 Stack Overflow 上提出了类似的问题：

VS2013 Typescript: Referencing and debugging with multiple projects Typescript debug ts files that are in other project Cross-project references between two projects

但这些问题都不符合本问题中指出的所有要求。以下是这些问题中发布的答案不符合我们需求的原因：

在 Visual Studio 中递归或手动链接文件的问题

调试和转到定义都不能很好地工作，或者根本不能在链接文件上工作。调试 ASP.NET 网站时链接的文件不存在。 一些有用的插件将每个链接文件视为一个单独的文件，这会减慢整个解决方案的代码审查和调试速度（例如，单个链接共享文件中的错误将显示为三个单独的错误：一个针对原始文件，一个用于引用项目 A，一个用于引用项目 B)。 不雅。

将文件从共享项目复制到引用项目的问题

无论您多么小心，您很有可能会直接编辑复制文件，而不是原始共享文件；重建时，复制文件中的所有更改都将丢失。 链接文件的问题也适用于此。

简单引用共享项目 TypeScript 文件的问题

生成的映射文件是多系统调试所需的，不指向共享项目。相反，它指向路径相关的文件引用，这会破坏共享文件的调试。

其他要求

我们需要保留将共享 TypeScript 直接构建到每个引用应用程序中的能力，而不是使用单独的共享网站然后包含该共享代码，因为引用应用程序针对不同的 ECMAScript 版本（例如，用于公共网站的 ECMAScript3 和 ECMAScript 5/6 对于您可以指定最低浏览器版本的管理网站）和不同的应用程序引用不同的共享文件（引用项目通过不同的 reference.ts 文件引用共享项目中的不同文件组，从而保持引用整洁）。 在开发环境中通过共享网站进行调试是可以的，但对于生产构建，共享代码需要直接构建到引用项目中。 在每个引用项目中，所有 TypeScript 文件（包括共享文件）都编译成一个名为 App.js 的文件。 确保可以在 Visual Studio 之外进行调试（这样我们就可以使用 Chrome、Firefox 和其他支持地图文件的浏览器进行调试，也可以在 Visual Studio/Internet Explorer 中进行调试）。

任何人都对此问题有解决方案，或者知道 Microsoft 是否正在将跨项目引用（包括完整的调试支持）构建到 Visual Studio 2015 中？

【参考方案1】：

我们可以想出的满足所有要求的最佳解决方案包括以下步骤：

添加对共享 TypeScript 文件的引用（使用特殊的 _references.ts 文件，或直接在 TypeScript 文件中引用）。

使用 PowerShell 自动更新 TypeScript 生成的地图文件，使其指向共享 Web 应用程序的项目 URL 或虚拟目录（适用于 IIS Express 和完整 IIS）。

我知道这看起来需要做很多工作，但设置时间应该不会超过 30 分钟。它工作得很好，从长远来看可以节省开发工作和时间：

1。添加对共享 TypeScript 文件的引用

Visual Studio 使这变得简单：将 TypeScript 文件（单个文件或 _references.ts 文件）从共享项目拖到引用项目的 _references.ts 文件或任何其他 TypeScript 文件（_references.ts 可以保持引用很好和整洁，但它可能不会使所有项目结构受益）。请注意，_references.ts 文件必须始终位于项目的根目录中才能按预期工作。

来源

Visual Studio 2013 Typescript compiler isn't respecting '_references.ts' file http://blogs.msdn.com/b/typescript/archive/2013/12/05/announcing-typescript-0-9-5.aspx。

2。使用 PowerShell 自动更新 TypeScript 生成的地图文件（以启用调试）

此步骤使用适用于 Visual Studio、Chrome 和 Firefox 调试的方法确保共享引用指向原始共享文件（将相对共享引用替换为项目 URL 或虚拟目录）。

致微软：这种类型的引用在未来的 Visual Studio 版本中应该是可配置和/或自动化的，例如如果从不同的项目引用文件，则自动将引用映射到共享项目的项目 URL。

选项 1：您的共享代码位于 Web 应用程序项目中。

这适用于多个调试系统（使用 Visual Studio、Chrome 和 Firefox 测试）：

从属性 | 获取共享应用程序项目 URL网站 |项目网址。

使用构建后事件运行 PowerShell 脚本，该脚本将替换 App.js.map 文件中的所有共享引用以指向项目 URL。

构建后命令示例：

Powershell [io.file]::WriteAllText('$(ProjectDir)Scripts\App.js.map', ((gc '$(ProjectDir)Scripts\App.js.map') -replace '../../Shared_TypeScript/','http://localhost:12345/'))

有关更多详细信息，请参阅下面来源下的 PowerShell 替换。

确保将共享 Web 应用项目设置为与引用的 Web 应用项目一起进行调试。

选项 2：您的共享代码不在 Web 应用程序项目中。

这不适用于 Visual Studio 调试，但在某些情况下可能是更好的选择，并且它是非 Web 应用程序项目的唯一已知选项（使用 Chrome 测试，可能适用于 Firefox）：

将虚拟目录添加到指向共享 TypeScript 项目的 IIS Express 网站配置：https://***.com/a/8929315/2033465（请参阅编辑）。

使用构建后事件运行 Powershell 脚本，该脚本将替换 App.js.map 文件中的所有共享引用，以指向您在上面设置的虚拟目录。

构建后命令示例：

Powershell [io.file]::WriteAllText('$(ProjectDir)Scripts\App.js.map', ((gc '$(ProjectDir)Scripts\App.js.map') -replace '../../GlobalRef/','/GlobalRef/'))

有关更多详细信息，请参阅下面来源下的 PowerShell 替换。

来源

PowerShell 替换：VS2010 Post-build event, replace string in a file. Powershell?

如果您需要能够在生产环境中调试 TypeScript 文件（不是我们的要求之一），那么您可以更改构建后脚本以运行不同的命令（类似，但指向您共享网站的虚拟目录而不是本地主机）。这超出了本文的范围。

结论

这是迄今为止我能想到的满足所有要求的最佳方法（感谢所有其他来源）。

如果您有更好的方法，请告诉我们。

【参考方案2】：

我正在解决类似的问题。我的要求是：

在一个解决方案中拥有多个项目，其组织方式与 C# 项目相同，因此解决方案文件夹包含 .sln，每个项目的子文件夹包含 .csproj 和 typescript 文件。

在 VS 和 IE11 中的调试可能性（通过 F5 运行断点和所有很酷的东西）

理想情况下无需额外的脚本。

我试过了：

postbuild powershell 脚本将源复制到 www 根 src 以启动项目为 wwwroot 的方式组织项目，其他项目放在 wwwroot 的 src 文件夹下（因此在 /src 文件夹下的启动项目文件夹内）

两种解决方案都在使用适当的 tsconfig（根据需要设置了映射），它可以正常工作，但我并不满意。

在第一种情况下，问题在于文件的更新。它在重建后就可以工作，所以它不太舒服，因为它需要重新启动 IE，构建所有内容，复制所有内容，并且需要花费很多时间。但它或多或少都有效。

第二个解决方案更好，但我被指责项目结构混乱和奇怪（我从头开始知道，我也不喜欢它）。

所以我更深入地解决了这个问题，并提出了虚拟目录的解决方案。现在，项目结构与标准 C# 项目结构匹配，可以在 IE11 和外部使用 Chrome 进行调试（在 IIS Express 和相同的 localhost:port 上），也可以正确使用“保存时编译”，包括 ie css 修改和页面重新加载，而不是重新构建和 IE 重启。

可以手动（无需额外的脚本）或通过 IIS express (.vs/config/application.host) 和 IIS 上的构建后脚本自动实现这一点（我直到现在才需要完整的 IIS，但是我很确定可以通过命令行自动化它）。如果您不会经常操作项目，我会说手动更新 IIS / applicationhost.config 文件就足够了并且效果很好（当然，当正确设置 tsconfig 以生成映射文件并为您的 TS 文件设置 sourceRoot 时）。

   Search for the 
   .vs/config/applicationhost.config -> <system.applicationHost> -> <sites> -> <site name="YOUR-STARTUP-PROJECT">
   for each project in the solution add\
   <virtualDirectory path="/src/YourSoultionProject1Name" physicalPath="C:\...PATH-TO-YOUR-PROJECT-ROOT-FOLDER-ON-DISK">

对于每个项目，也不要忘记将 tsconfig 文件的 sourceRoot 选项设置为 /src/YOUR_PROJECT_NAME（或在项目属性中配置 ts 编译器）

这是迄今为止我找到的最佳解决方案。只有一个问题是 .vs 与用户相关，通常不会转移到 repo，因此每个用户都必须自己设置它。这就是（其他人）我提出以下解决方案的原因

---

我决定创建额外的 - 构建 - 项目，我一开始想避免但它允许我这样做：

在项目打开或构建后，根据解决方案中的项目自动设置虚拟目录 根据解决方案配置（调试/发布）和项目内容构建 wwwroot。这包括： 处理 LESS/SASS 缩小 JS/CSS/html 为离线应用支持生成 cache.manifest 在 IE 中从 Visual Studio 调试或在 Chrome 外部调试 像往常一样通过 Web 项目发布到 Azure 清理 wwwroot 和 js 文件夹 监控解决方案中任何项目中任何文件的更改并将更改应用到目标文件而无需重建（基于 gulp watch）

我差不多完成了，我会在完成后将链接放在这里，只是为了让您了解我是如何进行的。

它是如何工作的（它将在自述文件中，但现在只是简单地解释一下）：

目前，我在解决方案中有 6 个项目，其中 5 个是具有适当 tsonfig 和/或 HTML/LESS/SASS/CSS/JSON/IMG 资源的“真正”TypeScript 代码。

所有项目都基于“带有 TypeScript 的 HTML 应用程序”模板。创建后我已经从它们中删除了所有内容（包括 web.config），因此它现在只包含我的文件。我还设置了对项目的引用，以便能够遵循所需的构建顺序。所有 typescript 项目都将 TS 转换为所属项目（包括地图文件和 d.ts，如果需要）的 bin 文件夹（我的 tsconfig 直接编译器只创建一个单个 js 文件，但它也适用于多个）。然后其他项目使用tsconfig中的相对路径（../libproject/bin/lib./d.ts）引用其他项目的bin文件夹中的d.ts。

我尝试像 C# 那样复制到依赖项目。它可以工作，但需要更多的工作和时间才能使其正常工作（包括干净。Postbuild 事件并不理想）。

第 6 个项目是“构建”和启动项目，因此它不包含任何“真实”代码（除了我需要的构建工具）。它基于 gulp 和我为阅读解决方案/项目信息和配置而编写的一些脚本。

它还会从每个控制 wwwroot 构建过程的项目中读取我的自定义配置。最后，它是将解决方案项目中的资源复制/处理（缩小）到此构建/启动项目。

我希望我明天能完成第一个版本并将其发布到 GitHub，以便您可以查看它并最终使用至少部分代码。您需要安装 node.js。