Параллельная сборка машинописного текста

Фон:

У нас есть несколько проектов ASP.NET с общим ядром. Статика из Core копируется во все остальные проекты. Мы добавили TypeScript во все наши проекты.

Вот как выглядит сборка TypeScript в csproj:

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

Когда файлы TypeScript компилируются, все файлы ссылок также компилируются. Некоторые файлы TypeScript ссылаются на файлы из основного проекта. Так, файлы из проекта 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 также вызывает сборку Common.ts из Core.

Проблема:

Не проблема, что некоторые файлы собираются несколько раз. НО - если мы строим проекты параллельно (и это поведение VS по умолчанию!) - иногда сборка аварийно завершается с исключением:

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

Причина в том, что два или более проектов пытаются создать файлы TypeScript и пытаются создать файлы, на которые ссылаются, из какого-то общего проекта. Один проект начинает сборку файла ts в файл js и блокирует файл js. Другой проект пытается заблокировать тот же файл и падает.

Итак, вопрос - как избежать таких параллельных сборок/блокировок? Ссылочный проект должен быть уже скомпилирован, поэтому, может быть, компилятор TypeScript не будет каким-то образом создавать файлы из других проектов?


typescript msbuild parallel-builds
person VorobeY1326    schedule 22.10.2015    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я справляюсь с этим, отправляя общие библиотеки в виде пакета NuGet. Это не только делает ваши сборки независимыми, но и позволяет вам контролировать свои зависимости (т. е. вы можете обновиться, когда захотите, а не только потому, что кто-то отредактировал общий файл).

person Fenton    schedule 22.10.2015

arrow_upward
0
arrow_downward

Я предлагаю вам относиться к проекту Common как к библиотеке, а не как к набору отдельных файлов.

Когда вы обращаетесь к 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 будут конфликтовать и переопределять друг друга. Ссылки по объявлениям типов решают эту проблему, а также вашу конкретную проблему разрывов сборки.

person seva titov    schedule 24.10.2015