Wie lässt sich das Veröffentlichen von Web-Apps mit Build-Beschleunigung/FUTDC im VS-Build angenehm gestalten? ⇐ C#

[Anonymous]

Ich habe ein Setup, in dem es eine Webanwendung und mehrere Bibliotheken mit Controllern, Razor-Ansichten und statischen Inhalten unter wwwroot gibt. Etwa so:

Code: Select all

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

In diesem Beispiel gibt es nur eine Bibliothek, es könnte aber mehr sein.
Sie ist so konfiguriert, dass sie beim Build in ihrem eigenen Bin-Verzeichnis veröffentlicht:

Code: Select all

$(OutputPath)
$(PublishDir)
true

Nach dem Ausführen von dotnet build sieht das bin-Verzeichnis der Webanwendung also folgendermaßen aus:

Code: Select all

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 !]>

Und die CSHTML-Ansichten werden in die WebProcessorLibrary.dll-Assembly kompiliert – überprüft.
Alles ist in Ordnung.
Jetzt öffne ich die Lösung in VS IDE. Build-Beschleunigung und FUTDC sind aktiviert – verifiziert.
Mein Szenario:

• Berühren Sie einen statischen Inhalt, zum Beispiel .\tests\apps\WebProcessorLibrary\wwwroot\Content\Site.css
• Build in VS IDE
• Überprüfen Sie, ob der statische Inhalt veröffentlicht ist (was nicht der Fall ist).

Beobachten:

Code: Select all

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 !]>

Der neue Zeitstempel ist also 20:56 Uhr, aber der veröffentlichte Inhalt ist immer noch um 20:54 Uhr.
Lassen Sie uns nun die Lösung in der VS-IDE erstellen (das WebProcessorLibrary-Projekt zielt sowohl auf net472 als auch auf net9.0 ab und wird in ein separates, gemeinsam genutztes Bin-Verzeichnis für Bibliotheksprojekte erstellt, d. h. die Web-App wird in ihr eigenes Verzeichnis integriert):

Code: Select all

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 hat also den Build für WebProcessorLibrary an den msbuild übergeben, aber die DLL wurde natürlich nicht aktualisiert:

Code: Select all

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 !]>

Der DLL-Zeitstempel von 20:49 Uhr liegt vor dem Zeitstempel der berührten CSS-Datei. Und das macht Sinn, da die CSS-Datei keine Abhängigkeit von der Binärdatei ist und wir das auch nicht wollen.
Aber es bedeutet auch, dass der veröffentlichte statische Inhalt auch nicht aktualisiert wurde:

Code: Select all

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 !]>

Das ist ein Problem.
Was ist der richtige Weg, um es zu beheben, ohne Folgendes zu tun:

• Deaktivieren von FUTDC für jedes Projekt
• Deaktivieren der Build-Beschleunigung für jedes Projekt (es ist aktiviert – verifiziert)
• Führt dazu, dass C#-Code aufgrund statischer Inhaltsänderungen neu kompiliert wird

BEARBEITEN 1
Ich weiß, wie ich FUTDC veranlassen kann, das AspNetCoreTest-Projekt an msbuild zu übergeben, wenn sich der statische Inhalt nachgelagert ändert:

Code: Select all

Dieser Ansatz weist jedoch drei Probleme auf:

• Er ist darauf angewiesen, dass der Design Time Build ausgeführt wird, bevor wir den Code erstellen. Was nicht zuverlässig geschieht.
• Es führt dazu, dass msbuild eine Menge Logik durchbrennt, um herauszufinden, dass es nur die Inhaltsdateien kopieren muss – der Hauptgrund, warum FUTDC überhaupt existiert.
• Microsoft scheint dies nicht in seinen eigenen Build-Zielen implementiert zu haben, obwohl sie es offensichtlich hätten tun können. Das lässt mich darüber nachdenken, ob sie eine bessere Idee haben.

Eine andere Option besteht darin, dotnet watchPublish --no-hot-reload --no-build -c:Debug neben der VS-IDE laufen zu lassen, aber das bedeutet, dass Entwickler mehr Dinge auslagern müssen – ein weiterer Fehlerpunkt.