RCL + Libman: Restored files don't get packed / published at the correct location in final app.
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- csharp
- Domain
- build-system
Research direction
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.
Written by the indexing model from the issue text.
Description
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>
...
- Dominant language
- C#
- Stars
- 486
- Forks
- 91
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from aspnet/LibraryManager
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
aspnet/LibraryManager#824 · 1 comment · 3 reactions ·
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
aspnet/LibraryManager#804 · 2 reactions ·
-
Difficulty 1/5 Under an hour Newbie friendliness 48/100
aspnet/LibraryManager#829 · 1 comment · 3 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
aspnet/LibraryManager#820 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
aspnet/LibraryManager#808 · 5 comments ·
All issues in aspnet/LibraryManager
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Type: enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
apache/arrow-adbc#4809 ·
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
microsoft/vscode-azurefunctions#5197 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
microsoft/microsoft-ui-reactor#1274 ·