-
Notifications
You must be signed in to change notification settings - Fork 5k
Need to ensure Path.GetTempPath() / other APIs work as expected on cross-plat coreclr fwk #4027
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
Comments
@MattGal, have you seen a problem at run time, or is this just based on code inspection? P/Invokes to kernel32.dll in mscorlib get redirected by the runtime to its PAL layer, so a call to GetTempPath on Unix doesn't actually try to load kernel32.dll, but instead uses the native implementation from libcoreclr. Today I believe it only goes to /tmp/, but it could certainly be extended to first check an environment variable, and that is indeed the plan for when Path is instead exposed in a standalone System.Runtime.Extensions library implemented in managed code over on https://github.com/dotnet/corefx. |
Same issue here. |
@felipepaixao, can you elaborate on the issue you're seeing? How is it failing? |
Hi, @stephentoub [EDIT] It happens when I try to Sign in asynchronouslly in (SignInManager.PasswordSignInAsync). So i don't have any control over the temporary targeted path.
|
Thanks. This is using the ASP.NET BufferingHelper, which is a wrapper around Path.GetTempPath(), but only as a fallback: |
Hey!
|
@felipepaixao, thanks. I was curious about the configuration of your machine. A few questions:
|
Hi, @stephentoub |
Excellent, thanks. |
I can chime in here. We added ASPNET_TEMP because IIS usually runs without a user profile under a service account. In those cases without carefully choosing a temp path, it ends up in a bizzare folder (system32 something). When we run in IIS, Helios (the IIS native module) sets ASPNET_TEMP to something appropriate. When running self hosted however, the intent was to fall back to the regular temp path. |
@stephentoub This is also likely a mono stacktrace as nobody has built core clr dnx besides @ellismg and I 😄 |
Thanks, David. Regarding Mono, that's what I was assuming, but, well, we all know what happens when people assume 😄 Hence the questions. |
There doesn't actually appear to be a CoreCLR problem here, and with dotnet/coreclr@43e2851 we now also check TMPDIR prior to just returning /tmp/, so I'm closing this. If an issue is discovered here subsequently, we can reopen or open a new issue. |
See this thread:
aspnet/HttpAbstractions#168
... basically the expectation is that Path.GetTempPath() may fail on Unix or MacOS systems when switching to the cross-plat coreclr implementation. From reading the current implementation, it still depends on the API in Kernel32.
The text was updated successfully, but these errors were encountered: