Is there a new temp path behaviour in ArcGIS 10.1?

[FossiG_]

Hi,

apparently since version 10.1 ArcMap creates its own temporary folder in the systems temp path. One folder for each ArMap-Process. The folders created look like this (where ...\Temp\ represents the systems temp path aka %temp%).

...\Temp\arcB\
...\Temp\arc27\
...\Temp\arc29\
...\Temp\arc2B\

This itself would be no problem, but it looks like ArcMap also changes the systems %temp% environment variable for its process.

If an AddIn determines the temp path it no longer gets the systems path, but rather the temp-directory of the current ArcMap-process it was called from, eg. ...\Temp\arc27\ instead of ...\Temp\

c#-Snippet used in our AddIns:

string tempPath = System.IO.Path.GetTempPath();

Is there any way, to get the old behaviour back?

The new directory is not a problem but why must ArcMap dynamically change the %temp% environment variable?

TIA,
Fossi

[Mariannevon_den_Driesch]

Hi,
we found the same problem and asked the ESRI Support for help.
We've received a response that this issue has been documented in ESRI Inc. now under NIM086862 "Incorrect temporary path is returned through add-in ArcGIS 10.1".
Under http://support.esri.com/ or http://resources.arcgis.com/en/home/ we should be able to track the status. Currently, we find there, however, no entry.
Kind regards,
geodok_dev

[Anonymous User · Accepted solution]

As a workaround you can get the environment variables through a different call.

Compare the following outputs

MessageBox.Show("temppath: " + Path.GetTempPath());
MessageBox.Show(Environment.GetEnvironmentVariable("TEMP",EnvironmentVariableTarget.User));

Change EnvironmentVariableTarget to user, process or machine as required.
Hope this helps.

[Mariannevon_den_Driesch]

Hello Sean,

thanks for the workaround, this solves my problem.

Kind regards,
Marianne

[FossiG_]

Hello Marianne, Hello Sean,

thanks for bringing this post up again.

Yes, the mentioned workaround avoids the problem. +1

BUT: It is very annoying, that any component executed in the context of an ESRI 10.1 Add-In suffers from this behaviour. I am using an external assembly as connector to another application. This assembly also gets this twisted path, when called from an ArcMap 10.1 Add-In. Executed from any other source, the temp path is correct.

So this problem goes beyond the Add-In itself and therefore this or any other workaround sadly has to be implemented in every dependent component, too. IMHO this is a bug.

Kind regards,
Fossi

[JonMorris2]

This is still a bug in 10.3. I found it on the support site and status is still New, so we'll have to keep using the workaround.

NIM086862: Incorrect temporary path is returned through Add-In..