I’m facing a weird issue while working with .NET Aspire npm app integration in WSL2 using JetBrains Rider Remote Development.
My current setup:
Using the default Aspire template as base
.NET 9 backend running in WSL2 environment
React frontend application
My AppHost configuration is something like this:
var appBuilder = DistributedApplication.CreateBuilder(args);
var backendApi = appBuilder.AddProject<Projects.MyApp_Backend>("backend-api")
.WithHttpHealthCheck("/api/health");
appBuilder.AddNpmApp("react-app", "../ReactClient/my-app", "start")
.WithHttpEndpoint(env: "PORT")
.WithExternalHttpEndpoints()
.WithReference(backendApi)
.WaitFor(backendApi);
appBuilder.Build().Run();
The error I’m getting when running through Rider Remote Development is:
/usr/bin/env: 'bash\r': No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines
Interestingly, when I launch the same code using VS Code with WSL, everything works perfectly.
It seems like the AddNpmApp method is causing this issue. My guess is that Rider might be interfering with line endings or the bash environment somehow. I’ve verified that my WSL files are using Unix line endings, but the error still occurs.
Has anyone encountered this bash\r error when using Aspire’s npm app functionality in WSL2 with Rider? Any suggestions on how to resolve this or ensure proper line endings for the npm scripts?
This bash line ending nightmare is exactly why I ditched manual WSL2 setups. Instead of hunting down git configs and running dos2unix every time Rider messes with your files, just automate the whole thing.
I use Latenode for workflows that handle all the environment prep. Set up a scenario that monitors project files, converts line endings automatically, syncs WSL2, and manages npm dependencies. No more guessing if Rider broke something.
The real win? Trigger the whole pipeline when switching between tools or pulling changes. Takes 10 minutes to set up once, then you’re done worrying about it.
You can extend it for other WSL2 headaches too - port forwarding issues, dependency conflicts between Windows and Linux environments.
Had this exact issue last week! Check your npm scripts in package.json - Rider sometimes copies them with wrong line endings. Run dos2unix package.json in WSL to fix it. Also check if shell scripts in node_modules got corrupted when Rider synced.
I encountered a similar issue and found that modifying the git configurations in WSL significantly helped. Rider’s interaction with line endings can truly be tricky, unlike VS Code’s straightforward handling. After adjusting the git settings by executing git config --global core.autocrlf false and git config --global core.eol lf in your WSL terminal, it should address the problem. Additionally, ensure no .gitattributes file interferes with these configurations, and confirm that Rider is mounting your project files correctly. This way, you can avoid any unwanted line ending conversions.
check your rider’s wsl integration settings - there’s usually a line ending conversion option that’s enabled by default. i had the same issue and turning off “convert line separators” in wsl settings fixed it. no need for extra scripts or git config changes.
This happens because Rider messes with WSL2 file system interactions and creates mixed line endings in npm’s internal scripts. When Rider fires up the npm environment through AddNpmApp, it accidentally triggers Windows-style line endings in bash scripts that npm creates or tweaks during startup. I fixed this by adding a pre-script hook in my React app’s package.json that cleans up line endings before the main start command kicks in. Try “prestart”: “find ./node_modules/.bin -type f -exec sed -i ‘s/\r$//’ {} + 2>/dev/null || true” - works great. This catches the issue at npm level instead of fighting Rider’s behavior. The main difference is VS Code handles the WSL2 file system bridge directly while Rider adds an extra layer that sometimes keeps Windows attributes around.
This happens because Rider’s file sync between Windows and WSL2 messes up line endings. Rider transfers files but keeps Windows CRLF endings instead of converting to Unix LF format, which breaks the executable scripts npm needs.
I fixed it by tweaking Rider’s deployment settings. Go to Settings > Deployment > Options and uncheck “Preserve files timestamps” plus enable “Delete target items when source ones do not exist.” Also check your WSL2 mount options in /etc/wsl.conf - add the metadata option so file permissions work properly.
What really helped was creating a startup script in my React project that runs find . -name "*.sh" -exec dos2unix {} \; before npm commands. This automatically fixes any corrupted scripts from the sync without having to do it manually every time.