LibMan installed libraries are not picked up by MapStaticAssets
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/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 csproj integration using Microsoft.Web.LibraryManager.Build, especially the LibraryManagerRestore target and the static web assets targets named in the report. Reproduce with dotnet publish and inspect the generated PROJECTNAME.staticwebassets.endpoints.json. Done means libraries restored into wwwroot/lib appear in that manifest even when the folder did not exist before the build.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
When using .NET 9's MapStaticAssets, existing assets in wwroot are picked up and compressed during build.
However, using Microsoft.Web.LibraryManager.Build, the libraries installed via libman in wwwroot/lib are not picked up.
I've tried numerous combinations of adding a target that tries to trigger the LibraryManagerRestore target before various other targets that sound like they are looking for assets (like ResolveStaticWebAssetsInputs or ResolveProjectStaticWebAssets) but none of that seems to work.
To Reproduce
Steps to reproduce the behavior:
- Create a csproj that uses the ASP.NET web SDK with library manager (including
Microsoft.Web.LibraryManager.Build) and restores libraries using libman intowwwroot/lib - run
dotnet publish --configuration release --output ./dist - Check the generated static web assets file in the output (
cat dist/PROJECTNAME.staticwebassets.endpoints.json) - Find that it does not contain any files that were restored by libman in
wwwroot/lib
Expected behavior
LibMan restored files are included in the static web assets manifest.
Additional context
Note that this is rather hard to reproduce in an IDE, since it will usually automatically restore the libman libraries.
If the wwwroot/lib folder exists BEFORE the build is started, it is also correctly picked up by the static web assets tooling.
We've hit the problem during CI builds.
dotnet --version: 9.0.305
Microsoft.Web.LibraryManager.Build: 3.0.71
- Lenguaje dominante
- C#
- Estrellas
- 486
- Forks
- 91
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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.114 Abierto
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
-
core dependencies
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
-
bug frontend good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
NavigationViewItemAutomationPeer implements IInvokeProvider but never advertises the Invoke pattern Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
unoplatform/uno#24629 ·
-
agentic-workflows Needs: Triage :mag: State: In-PR
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Down / Waiting for removal
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100