To get runtime case-sensitivity problems with filenames I guess you must be doing something like having resource files as part of your project and then loading them from disk at runtime, but the code that loads them is being told the slightly wrong filename. Depending on why you need to load those files, there's not much you can do about that except stop coding the wrong filenames!
There are things that can help with filesystem differences though, if you're not using them already look under the System.IO namespace
Path.Combine will combine path segments using the native directory separator either `/` or `\`.
Path.GetTempFileName will create a temporary file on disk so you don't need to know if that's `/tmp` or `C:\whereverwindowsputsit\`
Mostly everything just works when coding on Windows and deploying to Linux, I think it is only the filesystem differences that ever cause problems and even then it's down to coding mistakes.
I guess watch out for different line endings in files "\r\n" in Windows, "\n" in Linux. The best thing to do there if possible is use tools in Windows that preserve Linux line endings so you never see "\r\n" in Linux at runtime.
If you're using classes under the System.Drawing namespace then a lot of functionality is missing in Linux, but I don't know much about that. The 3rd party ImageSharp library fills some of the gap and is just generally awesome.
Other than that, I'm sure there's niche things but nothing is coming to mind!
I can run it in WSL, but since my development happens on Windows I have to copy the build output into the WSL environment and run it there. I automated it a bit, but it still adds noticeable overhead and slows down the feedback loop.
So I usually only test there when I suspect a Linux-specific issue (case sensitivity, paths, permissions, etc.).
To get runtime case-sensitivity problems with filenames I guess you must be doing something like having resource files as part of your project and then loading them from disk at runtime, but the code that loads them is being told the slightly wrong filename. Depending on why you need to load those files, there's not much you can do about that except stop coding the wrong filenames!
There are things that can help with filesystem differences though, if you're not using them already look under the System.IO namespace
Path.Combine will combine path segments using the native directory separator either `/` or `\`.
Path.GetTempFileName will create a temporary file on disk so you don't need to know if that's `/tmp` or `C:\whereverwindowsputsit\`
Mostly everything just works when coding on Windows and deploying to Linux, I think it is only the filesystem differences that ever cause problems and even then it's down to coding mistakes.
Most of the issues I hit were indeed small mistakes that Windows silently tolerated (like casing differences or hardcoded separators).
Linux just makes them visible much earlier.
I'll definitely take another look at the System.IO helpers you mentioned to avoid some of that.
Are there any other common pitfalls you’ve seen when running .NET apps on Linux that are easy to overlook?
I guess watch out for different line endings in files "\r\n" in Windows, "\n" in Linux. The best thing to do there if possible is use tools in Windows that preserve Linux line endings so you never see "\r\n" in Linux at runtime.
If you're using classes under the System.Drawing namespace then a lot of functionality is missing in Linux, but I don't know much about that. The 3rd party ImageSharp library fills some of the gap and is just generally awesome.
Other than that, I'm sure there's niche things but nothing is coming to mind!
Why not run the build in WSL?
That's a fair point.
I tried running it in WSL, but my usual workflow is still centered around Windows tooling, so it adds a bit of friction to the inner dev loop.
Maybe moving more of the build pipeline into WSL would actually be the cleaner approach long term.
Have you tried debugging it locally in a WSL instance?
Yes, I tried that.
I can run it in WSL, but since my development happens on Windows I have to copy the build output into the WSL environment and run it there. I automated it a bit, but it still adds noticeable overhead and slows down the feedback loop.
So I usually only test there when I suspect a Linux-specific issue (case sensitivity, paths, permissions, etc.).