Vault CLI client - settings.xml location?

[rptodd]

We have a web application that calls the Vault command line client.
Recently, we created another instance, configured to run under a different application pool in IIS.
Then new instance is getting the following error. If we switch to the application pool the original instance runs under, everything works fine.
Where is the settings.xml file usually located? Does running under an IIS application pool change where that goes?
thanks!

<vault>
<error>
<exception>System.Exception: Couldn't calculate a local settings path for settings.xml. Tried both "" and "SourceGear".
at VaultLib.LocalSettingsCore.VaultClientConfigReader..ctor(String scope, String strDefLocation)
at VaultLib.LocalSettingsCore.Init(LocalSettingsScope scope, String strDefaultConfigDir)
at VaultClientOperationsLib.ClientInstance.Init(AccessLevelType accessLevel)
at VaultClientIntegrationLib.ServerOperations.Login(AccessLevelType altCommand, Boolean bAllowAuto, Boolean bSaveSession)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
</error>
<result>
<success>False</success>
</result>
</vault>

[Tonya]

Hello,

Can you please send your Vault Server log to support@sourcegear.com? The Vault Server log is in %windir%\temp\sgvault\sgvault.log on the server machine.

When emailing support, please reference this post on the forum.

Thanks,

Tonya

[rptodd]

Thank you, this problem has been resolved.

The root cause was that on our IIS application pool settings under process model we had Load User Profile set to false. So Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) was returning C:WINDOWS\system32\config\systemprofile\AppData\Roaming .

I believe the proper solution would be to set Load User Profile to true to fix this. But since this is a legacy application, what we did was ensure the directory existed and granted full control to account the application pool runs under.
Fortunately we had the source code so we could debug through and examine the value returned from Environment.SpecialFolder.ApplicationData.

[Tonya]

Thank you for updating this thread with the resolution. Glad to know it's been resolved.

Tonya