1

背景:

我们有几个具有共同核心的 ASP.NET 项目。来自 Core 的静态被复制到所有其他项目。我们已将 TypeScript 添加到我们所有的项目中。

下面是 TypeScript 构建在 csproj 中的样子:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" />

编译 TypeScript 文件时,也会编译所有引用文件。一些 TypeScript 文件引用了 Core 项目中的文件。因此,Core 项目中的文件有时会被编译多次(如果其他项目中的多个文件引用它们)。

简单的例子:

Core.csproj
  -> Common.ts
A.csproj
  -> ScriptA.ts
B.csproj
  -> ScriptB.ts

ScriptA.ts:

/// <reference path="../Core/Common.ts" />
...

ScriptB.ts:

/// <reference path="../Core/Common.ts" />
...

A 或 B 项目的构建也会导致来自 Core 的 Common.ts 也被构建。

问题:

某些文件被构建多次不是问题。但是 - 如果我们并行构建项目(这是默认的 VS 行为!) - 有时构建会因异常而崩溃:

[VsTsc] VSTSC error TS5033: Build: Could not write file '...'

原因是两个或多个项目尝试构建 TypeScript 文件并尝试从某个常见项目构建引用文件。一个项目开始将 ts 文件构建为 js 文件并锁定 js 文件。其他项目试图锁定同一个文件并崩溃。

所以,问题是 - 如何避免这种并行构建/锁定?引用的项目必须已经编译,所以可以说 TypeScript 编译器不会以某种方式从其他项目构建文件?

4

2 回答 2

0

我通过将共享库作为 NuGet 包提供来处理这个问题。这不仅使您的构建独立,还使您可以控制依赖项(即,您可以在决定升级时进行升级,而不仅仅是因为有人编辑了共享文件)。

于 2015-10-22T18:22:04.373 回答
0

我建议您将项目 Common 视为一个库,而不是单个文件的集合。

当您使用 line 引用 Common 时/// <reference path="../Core/Common.ts" />,这会将 Common.ts - 可能还有它引用的文件 - 拉入项目 A 和 B,从而复制它,并使其编译多次。

相反,你需要的是

/// <reference path="../Core/Common.d.ts" />

也就是说,您只使用来自项目 Common 的声明。默认情况下不构建声明,您应该在项目配置的 TypeScript 页面上选中“生成声明文件”选项,或者如果您更喜欢手动添加行

<TypeScriptGeneratesDeclarations>True</TypeScriptGeneratesDeclarations>

在您的 .csproj 文件中。一个小缺点是您必须将多个 .js 文件加载到您的页面或 node.js 项目中。然而,为将代码组合成模块的能力付出的代价很小。例如,有一天您可能希望将 A.js 和 B.js 加载到同一个页面中,您会遇到一团糟,因为 common.ts 的副本会发生冲突并相互覆盖。通过类型声明引用解决了这个问题,以及构建中断的特定问题。

于 2015-10-24T22:44:46.063 回答