Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet watch ignores StaticWebAssetBasePath for third-party library #47802

Open
1 task done
Apollo3zehn opened this issue Apr 20, 2023 · 2 comments
Open
1 task done
Labels
area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate triaged

Comments

@Apollo3zehn
Copy link

Apollo3zehn commented Apr 20, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

I try to host a Blazor WASM app under the path <host>/dev using the property <StaticWebAssetBasePath>dev</StaticWebAssetBasePath>. My project is also referencing the third-party library MudBlazor and when I do dotnet publish -c Debug -o <path> the output is just fine, i.e. MudBlazor is below the dev/_content folder:

grafik

But when I run dotnet watch the files are not located under the dev/_content path but directly under _content (
the target framework is net7.0):
grafik

Expected Behavior

I expect that <StaticWebAssetBasePath>dev</StaticWebAssetBasePath> is also applied to third-party libraries when running dotnet watch.

Steps To Reproduce

  1. Run
dotnet new blazorwasm 
dotnet add package MudBlazor
  1. Edit the .csproj file and add <StaticWebAssetBasePath>dev</StaticWebAssetBasePath>.
  2. Run dotnet publish
  3. Have look into the published folder, it looks fine (_content/MudBlazor is located under wwwroot/dev).
  4. Run dotnet watch
  5. Try to load the file http://localhost:<your-port>/dev/_content/MudBlazor/MudBlazor.min.js: it fails
  6. Try to load the file http://localhost:<your-port>/_content/MudBlazor/MudBlazor.min.js: it succeeds

Exceptions (if any)

No response

.NET Version

7.0.101

Anything else?

VS Code watch task

The project Veltrup.Server references and serves the WASM client project.

grafik

dotnet --info

.NET SDK:
Version: 7.0.101
Commit: bb24aafa11

Laufzeitumgebung:
OS Name: ubuntu
OS Version: 22.10
OS Platform: Linux
RID: linux-x64
Base Path: /home/vincent/Dokumente/Software/dotnet/sdk/7.0.101/

Host:
Version: 7.0.1
Architecture: x64
Commit: 97203d38ba

.NET SDKs installed:
5.0.408 [/home/vincent/Dokumente/Software/dotnet/sdk]
6.0.404 [/home/vincent/Dokumente/Software/dotnet/sdk]
7.0.101 [/home/vincent/Dokumente/Software/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.17 [/home/vincent/Dokumente/Software/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.12 [/home/vincent/Dokumente/Software/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.1 [/home/vincent/Dokumente/Software/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.17 [/home/vincent/Dokumente/Software/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.12 [/home/vincent/Dokumente/Software/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.1 [/home/vincent/Dokumente/Software/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
DOTNET_ROOT [/home/vincent/Dokumente/Software/dotnet]

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI label Apr 20, 2023
@javiercn javiercn added the feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) label Apr 20, 2023
@rushangp1
Copy link

I'm facing this too

@mkArtakMSFT mkArtakMSFT added this to the .NET 9 Planning milestone Oct 6, 2023
@ghost
Copy link

ghost commented Oct 6, 2023

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate triaged
Projects
None yet
Development

No branches or pull requests

5 participants