Как сделать публикацию веб-приложений удобной с помощью ускорения сборки/FUTDC в сборке VS? - Цифровое Кемерово

Как сделать публикацию веб-приложений удобной с помощью ускорения сборки/FUTDC в сборке VS? ⇐ C#

Ответить

1 сообщение • Страница 1 из 1

Anonymous

Как сделать публикацию веб-приложений удобной с помощью ускорения сборки/FUTDC в сборке VS?

Цитата

Сообщение Anonymous » 10 янв 2026, 00:52

У меня есть установка, в которой есть одно веб-приложение и несколько библиотек, содержащих контроллеры, представления Razor и статический контент под wwwroot. Примерно так:

Код: Выделить всё

C:.
├───AspNetCoreTest
└───WebProcessorLibrary
├───Areas
│   └───TestArea
│       ├───Controllers
│       └───Views
│           └───AreaTest
├───Controllers
├───Views
│   ├───Home
│   └───Shared
└───wwwroot
├───Areas
│   └───TestArea
│       ├───Content
│       └───Scripts
├───Content
└───Scripts

В этом примере имеется только одна библиотека, но их может быть больше.
Она настроена на публикацию при сборке в собственный каталог bin:

Код: Выделить всё

$(OutputPath)
$(PublishDir)
true

Итак, после запуска сборки dotnet каталог bin веб-приложения выглядит следующим образом:

Код: Выделить всё

C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\AspNetCoreTest\bin\Debug\net9.0\

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----            1/8/2026  8:49 PM                wwwroot
-a---            1/8/2026  8:49 PM           2030 AspNetCoreTest.deps.json
-a---            1/8/2026  8:49 PM           8704 AspNetCoreTest.dll
-a---            1/8/2026  8:49 PM         156672 AspNetCoreTest.exe
-a---            1/8/2026  8:49 PM          23444 AspNetCoreTest.pdb
-a---            1/8/2026  8:49 PM            416 AspNetCoreTest.runtimeconfig.json
-a---            1/8/2026  8:49 PM          42602 AspNetCoreTest.staticwebassets.endpoints.json
-a---            1/8/2026  8:49 PM           2310 AspNetCoreTest.staticwebassets.runtime.json
-a---            1/8/2026  8:49 PM           4608 Dayforce.Web.dll
-a---            1/8/2026  8:49 PM          22016 Dayforce.Web.NetCore.dll
-a---            1/8/2026  8:49 PM          28968 Dayforce.Web.NetCore.pdb
-a---            1/8/2026  8:49 PM          20936 Dayforce.Web.pdb
-a---            1/8/2026  8:49 PM          15872 TestModels.dll
-a---            1/8/2026  8:49 PM          35484 TestModels.pdb
-a---            1/8/2026  8:49 PM            558 web.config
-a---            1/8/2026  8:49 PM          84480 WebProcessorLibrary.dll
-a---            1/8/2026  8:49 PM          48424 WebProcessorLibrary.pdb
-a---            1/8/2026  8:49 PM          24416 WebProcessorLibrary.staticwebassets.endpoints.json
-a---            1/8/2026  8:49 PM           2154 WebProcessorLibrary.staticwebassets.runtime.json

C:\xyz [master ≡ +0 ~9 -0 !]>

И cshtml представления компилируются в сборку WebProcessorLibrary.dll — проверено.
Все в порядке.
Теперь открываю решение в VS IDE. Ускорение сборки и FUTDC включены — проверено.
Мой сценарий:

Прикоснитесь к статическому содержимому, например .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css
Создайте в VS IDE
Проверьте, опубликовано ли статическое содержимое (оно нет).

Обратите внимание:

Код: Выделить всё

C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css,.\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content\Site.css

Directory: C:\xyz\tests\apps\WebProcessorLibrary\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

C:\xyz [master ≡ +0 ~9 -0 !]> touch.exe .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css
C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css,.\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content\Site.css

Directory: C:\xyz\tests\apps\WebProcessorLibrary\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:56 PM           1792 Site.css

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

C:\xyz [master ≡ +0 ~9 -0 !]>

Итак, новая временная метка — 20:56, но опубликованный контент по-прежнему в 20:54.
Теперь давайте создадим решение в VS IDE (проект WebProcessorLibrary нацелен как на net472, так и на net9.0, и он строится в отдельном общем каталоге bin, предназначенном для проектов библиотеки, т. е. веб-приложение строится самостоятельно):

Код: Выделить всё

Build started at 8:57 PM...
1>------ Build started: Project: WebProcessorLibrary, Configuration: Debug Any CPU ------
1>WebProcessorLibrary -> C:\dayforce\DevOps\Dayforce.Web\tests\bin.core\Debug\net9.0\WebProcessorLibrary.dll
1>WebProcessorLibrary -> C:\dayforce\DevOps\Dayforce.Web\tests\bin\WebProcessorLibrary.dll
========== Build: 1 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
========== Build completed at 8:57 PM and took 02.340 seconds ==========

Итак, FUTDC передал сборку WebProcessorLibrary в msbuild, но DLL, конечно, не была обновлена:

Код: Выделить всё

C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\bin.core\Debug\net9.0\WebProcessorLibrary.dll, .\tests\apps\AspNetCoreTest\bin\Debug\net9.0\WebProcessorLibrary.dll

Directory: C:\xyz\tests\bin.core\Debug\net9.0

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:49 PM          84480 WebProcessorLibrary.dll

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:49 PM          84480 WebProcessorLibrary.dll

C:\xyz [master ≡ +0 ~9 -0 !]>

Временная метка dll 20:49 предшествует временной метке затронутого CSS-файла. И это имеет смысл, поскольку файл css не является зависимостью от двоичного файла, а мы этого не хотим.
Но это также означает, что опубликованный статический контент также не был обновлен:

Код: Выделить всё

C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css,.\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content\Site.css

Directory: C:\xyz\tests\apps\WebProcessorLibrary\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:56 PM           1792 Site.css

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

C:\xyz [master ≡ +0 ~9 -0 !]>

В чем проблема?
Как правильно ее исправить, не прибегая к каким-либо из следующих действий:

Отключение FUTDC для любого проекта
Отключение ускорения сборки для любого проекта (оно включено – проверено)
Вызывание перекомпиляции кода C# из-за изменений статического содержимого

РЕДАКТИРОВАТЬ 1
Я знаю, как заставить FUTDC передать проект AspNetCoreTest в msbuild при изменении статического содержимого в дальнейшем:

Код: Выделить всё

Однако у этого подхода есть три проблемы:

Он основан на том, что сборка времени разработки выполняется до того, как мы создадим код. Что не происходит надежно.
Это заставляет msbuild прожигать много логики, чтобы обнаружить, что все, что ему нужно сделать, это просто скопировать файлы содержимого - основная причина, по которой FUTDC вообще существует.
Похоже, что Microsoft не реализовала это в своих собственных целях сборки, хотя они, очевидно, могли бы это сделать. Это заставляет меня задуматься, есть ли у них идея получше.

Другой вариант — запустить dotnet watchPublish --no-hot-reload --no-build -c:Debug вместе с VS IDE, но это означает, что разработчикам придется выделить больше вещей - еще одна точка отказа.

Подробнее здесь: https://stackoverflow.com/questions/798 ... -in-vs-bui

1767995529

Anonymous

У меня есть установка, в которой есть одно веб-приложение и несколько библиотек, содержащих контроллеры, представления Razor и статический контент под wwwroot. Примерно так:
[code]C:.
├───AspNetCoreTest
└───WebProcessorLibrary
├───Areas
│   └───TestArea
│       ├───Controllers
│       └───Views
│           └───AreaTest
├───Controllers
├───Views
│   ├───Home
│   └───Shared
└───wwwroot
├───Areas
│   └───TestArea
│       ├───Content
│       └───Scripts
├───Content
└───Scripts
[/code]
В этом примере имеется только одна библиотека, но их может быть больше.
Она настроена на публикацию при сборке в собственный каталог bin:
[code]
$(OutputPath)
$(PublishDir)
true
[/code]
Итак, после запуска сборки dotnet каталог bin веб-приложения выглядит следующим образом:
[code]C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\AspNetCoreTest\bin\Debug\net9.0\

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----            1/8/2026  8:49 PM                wwwroot
-a---            1/8/2026  8:49 PM           2030 AspNetCoreTest.deps.json
-a---            1/8/2026  8:49 PM           8704 AspNetCoreTest.dll
-a---            1/8/2026  8:49 PM         156672 AspNetCoreTest.exe
-a---            1/8/2026  8:49 PM          23444 AspNetCoreTest.pdb
-a---            1/8/2026  8:49 PM            416 AspNetCoreTest.runtimeconfig.json
-a---            1/8/2026  8:49 PM          42602 AspNetCoreTest.staticwebassets.endpoints.json
-a---            1/8/2026  8:49 PM           2310 AspNetCoreTest.staticwebassets.runtime.json
-a---            1/8/2026  8:49 PM           4608 Dayforce.Web.dll
-a---            1/8/2026  8:49 PM          22016 Dayforce.Web.NetCore.dll
-a---            1/8/2026  8:49 PM          28968 Dayforce.Web.NetCore.pdb
-a---            1/8/2026  8:49 PM          20936 Dayforce.Web.pdb
-a---            1/8/2026  8:49 PM          15872 TestModels.dll
-a---            1/8/2026  8:49 PM          35484 TestModels.pdb
-a---            1/8/2026  8:49 PM            558 web.config
-a---            1/8/2026  8:49 PM          84480 WebProcessorLibrary.dll
-a---            1/8/2026  8:49 PM          48424 WebProcessorLibrary.pdb
-a---            1/8/2026  8:49 PM          24416 WebProcessorLibrary.staticwebassets.endpoints.json
-a---            1/8/2026  8:49 PM           2154 WebProcessorLibrary.staticwebassets.runtime.json

C:\xyz [master ≡ +0 ~9 -0 !]>
[/code]
И cshtml представления компилируются в сборку WebProcessorLibrary.dll — проверено.
Все в порядке.
Теперь открываю решение в VS IDE.  Ускорение сборки и FUTDC включены — проверено.
Мой сценарий:
[list]
[*]Прикоснитесь к статическому содержимому, например [b].\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css[/b]
[*]Создайте в VS IDE
[*]Проверьте, опубликовано ли статическое содержимое (оно нет).
[/list]
Обратите внимание:
[code]C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css,.\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content\Site.css

Directory: C:\xyz\tests\apps\WebProcessorLibrary\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

C:\xyz [master ≡ +0 ~9 -0 !]> touch.exe .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css
C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css,.\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content\Site.css

Directory: C:\xyz\tests\apps\WebProcessorLibrary\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:56 PM           1792 Site.css

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

C:\xyz [master ≡ +0 ~9 -0 !]>
[/code]
Итак, новая временная метка — 20:56, но опубликованный контент по-прежнему в 20:54.
Теперь давайте создадим решение в VS IDE (проект WebProcessorLibrary нацелен как на net472, так и на net9.0, и он строится в отдельном общем каталоге bin, предназначенном для проектов библиотеки, т. е. веб-приложение строится самостоятельно):
[code]Build started at 8:57 PM...
1>------ Build started: Project: WebProcessorLibrary, Configuration: Debug Any CPU ------
1>WebProcessorLibrary -> C:\dayforce\DevOps\Dayforce.Web\tests\bin.core\Debug\net9.0\WebProcessorLibrary.dll
1>WebProcessorLibrary -> C:\dayforce\DevOps\Dayforce.Web\tests\bin\WebProcessorLibrary.dll
========== Build: 1 succeeded, 0 failed, 6 up-to-date, 0 skipped ==========
========== Build completed at 8:57 PM and took 02.340 seconds ==========
[/code]
Итак, FUTDC передал сборку WebProcessorLibrary в msbuild, но DLL, конечно, не была обновлена:
[code]C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\bin.core\Debug\net9.0\WebProcessorLibrary.dll, .\tests\apps\AspNetCoreTest\bin\Debug\net9.0\WebProcessorLibrary.dll

Directory: C:\xyz\tests\bin.core\Debug\net9.0

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:49 PM          84480 WebProcessorLibrary.dll

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:49 PM          84480 WebProcessorLibrary.dll

C:\xyz [master ≡ +0 ~9 -0 !]>
[/code]
Временная метка dll 20:49 предшествует временной метке затронутого CSS-файла.  И это имеет смысл, поскольку файл css не является зависимостью от двоичного файла, а мы этого не хотим.
Но это также означает, что опубликованный статический контент также не был обновлен:
[code]C:\xyz [master ≡ +0 ~9 -0 !]> dir .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css,.\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content\Site.css

Directory: C:\xyz\tests\apps\WebProcessorLibrary\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:56 PM           1792 Site.css

Directory: C:\xyz\tests\apps\AspNetCoreTest\bin\Debug\net9.0\wwwroot\Content

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---            1/8/2026  8:54 PM           1792 Site.css

C:\xyz [master ≡ +0 ~9 -0 !]>
[/code]
В чем проблема?
Как правильно ее исправить, не прибегая к каким-либо из следующих действий:
[list]
[*]Отключение FUTDC для любого проекта
[*]Отключение ускорения сборки для любого проекта (оно включено – проверено)
[*]Вызывание перекомпиляции кода C# из-за изменений статического содержимого
[/list]
[b]РЕДАКТИРОВАТЬ 1[/b]
Я знаю, как заставить FUTDC передать проект AspNetCoreTest в msbuild при изменении статического содержимого в дальнейшем:
[code]
















[/code]
Однако у этого подхода есть три проблемы:
[list]
[*]Он основан на том, что сборка времени разработки выполняется до того, как мы создадим код. Что не происходит надежно.
[*]Это заставляет msbuild прожигать много логики, чтобы обнаружить, что все, что ему нужно сделать, это просто скопировать файлы содержимого - основная причина, по которой FUTDC вообще существует.
[*]Похоже, что Microsoft не реализовала это в своих собственных целях сборки, хотя они, очевидно, могли бы это сделать. Это заставляет меня задуматься, есть ли у них идея получше.
[/list]
Другой вариант — запустить dotnet watchPublish --no-hot-reload --no-build -c:Debug вместе с VS IDE, но это означает, что разработчикам придется выделить больше вещей - еще одна точка отказа. 

Подробнее здесь: [url]https://stackoverflow.com/questions/79863869/how-to-make-web-app-publishing-play-nice-with-build-acceleration-futdc-in-vs-bui[/url]

Ответить

1 сообщение • Страница 1 из 1

Быстрый ответ

Заголовок:

Имя пользователя:

Изменение регистра текста:

Смайлики

Ещё смайлики…

К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми. Можно прикреплять файлы, перетаскивая их в окно сообщения.

Максимально разрешённый размер вложения: 15 МБ.

Имя файла:

Комментарий к файлу:

Имя файла	Комментарий к файлу	Размер	Статус

Вернуться в «C#»