RCL + Libman: Restored files don't get packed / published at the correct location in final app.
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- csharp
- Área
- build-system
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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>
...
- Lenguaje dominante
- C#
- Estrellas
- 486
- Forks
- 92
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de aspnet/LibraryManager
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
aspnet/LibraryManager#824 · 1 comentario · 3 reacciones ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
aspnet/LibraryManager#804 · 2 reacciones ·
-
Changelog for 3.0.114Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 48/100
aspnet/LibraryManager#829 · 1 comentario · 3 reacciones ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
aspnet/LibraryManager#820 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
aspnet/LibraryManager#808 · 5 comentarios ·
Todos los issues de aspnet/LibraryManager
Issues similares
-
0 - Backlog Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
BrighterCommand/Brighter#4444 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
area:frontend bug FE P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
klasolsson81/jobbliggaren#1915 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
microsoft/vscode-copilotstudio#431 ·
Los mantenedores suelen responder en 2 días