RCL + Libman: Restored files don't get packed / published at the correct location in final app.
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- csharp
- Ambito
- build-system
Direzione di ricerca
Start with the ResolveCurrentProjectStaticWebAssetsInputs and LibraryManagerRestore targets described in the issue, and compare the pack and publish flows through the dotnet CLI and Visual Studio. Done means LibMan-restored files from an RCL are placed under wwwroot/_content// on the first pack or publish, without requiring a prior restore.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Copy from the original issue I filed in the AspNet.Core repo:
https://github.com/dotnet/aspnetcore/issues/34039
Describe the bug
Files that are restored with the Microsoft.Web.LibraryManager.Build (LibMan) inside a Razor Class Library (RCL) are not deployed to the correct location in the final consuming app (e.g. Blazor Server App).
Instead of being deployed to:
wwwroot/_content/<RCL Package Name>/
they are deployed to
wwwroot/
This happens only if the files are not yet restored when you pack / publish the app. Once the files are restore they are correctly deployed in subsequent builds.
dotnet version:
5.0.300
environments:
dotnet cli (e.g. dotnet pack)
Visual Studio (pack context menu)
Solution
I found out that the ResolveCurrentProjectStaticWebAssetsInputs target takes content files as its input. The LibraryManagerRestore on the other hand doesn't produce content items. If you apply the following workaround, the issue disappears:
...
<PropertyGroup>
<ResolveCurrentProjectStaticWebAssetsInputsDependsOn>LibraryManagerRestore;FixLibManRestore;$(ResolveCurrentProjectStaticWebAssetsInputsDependsOn)</ResolveCurrentProjectStaticWebAssetsInputsDependsOn>
</PropertyGroup>
<Target Name="FixLibManRestore" AfterTargets="LibraryManagerRestore">
<ItemGroup>
<Content Include="%(FilesForPackagingFromProject.Identity)" Exclude="@(Content)">
</Content>
</ItemGroup>
</Target>
...
- Lingua principale
- C#
- Stelle
- 486
- Fork
- 91
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di aspnet/LibraryManager
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
aspnet/LibraryManager#824 · 1 commento · 3 reazioni ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
aspnet/LibraryManager#804 · 2 reazioni ·
-
Changelog for 3.0.114 Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 48/100
aspnet/LibraryManager#829 · 1 commento · 3 reazioni ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
aspnet/LibraryManager#820 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
aspnet/LibraryManager#808 · 5 commenti ·
Tutte le issue di aspnet/LibraryManager
Issue simili
-
bug frontend good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
CS0162 "Unreachable code detected" warning from a MSBuildTemp .tmp file in every game project Apertabug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
Type: enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
apache/arrow-adbc#4809 ·