Clever Geek Handbook

Do you need write permission on the parent folder?

When trying to run an application in a folder where the current user does not have write access, the application crashes.

So my question is, does the .net app create temporary files in the parent folder by default?

And if so, can we explicitly set the installation path of the external folder where the application has write access to create its temporary files?

thank

EDIT: I came back with more details ... So the exception is System.UnauthorizedAccessException and the file it is trying to create is called "l1m5tzj4.tmp"

So now I'm pretty sure the .NET application is trying to create a temporary file in the current folder ...

Here is the stacktrace

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
   at System.CodeDom.Compiler.TempFileCollection.EnsureTempNameCreated()
   at System.CodeDom.Compiler.TempFileCollection.get_BasePath()
   at System.CodeDom.Compiler.TempFileCollection.AddExtension(String fileExtension, Boolean keepFile)
   at System.CodeDom.Compiler.TempFileCollection.AddExtension(String fileExtension)
   at System.Configuration.Internal.WriteFileContext..ctor(String filename, String templateFilename)
   at System.Configuration.Internal.InternalConfigHost.StaticOpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext, Boolean assertPermissions)
   at System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.OpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext, Boolean assertPermissions)
   at System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.OpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext)
   at System.Configuration.ClientConfigurationHost.OpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext)
   at System.Configuration.UpdateConfigHost.OpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext)
   at System.Configuration.MgmtConfigurationRecord.SaveAs(String filename, ConfigurationSaveMode saveMode, Boolean forceUpdateAll)

EDIT 2: It looks like it happens when I add a new value to the exe config file.

Configuration configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
if (configuration.AppSettings.Settings[key] != null)
{
    configuration.AppSettings.Settings[key].Value = value;
    configuration.Save();
    ConfigurationManager.RefreshSection("appSettings");
}

So why is it trying to create a temporary file while I am trying to save the config? And are there any recommendations for saving configurations when we don't have write access to its folder?

+3


source to share


1 answer


No, a .NET application by default does not create any (temporary or otherwise) files in the folder containing the executing assembly at run time.

Mechanisms that could do this, among others:

  • Tracing
  • entrance
  • Library artifacts such as ODP.NET Database Provider
  • Dynamic compilation, such as serializers

EDIT . More information is available by now, so we can also review your real-world scenario here:

You call Configuration.Save

that tries to update the filename.exe.config file. Now your question is why the system instead of just overwriting the existing config file creates a temporary file.

The reason is given by an unknown Microsoft programmer who commented:



The current algorithm guarantees 1) The file we are saving will always be present in the file system (i.e. there will be no window during saving, in which there will be no file there)
 2) It will always be readable from the client, and it will complete and accurate.

They first create a temporary file here where the new configuration is written. This is what you see unsuccessfully when your program throws an exception.

After that, they replace the original config file with a temporary file (execution never reaches your place), here .

And are there any recommendations for saving configurations when we don't have write access to its folder?

You can redirect the config file to any other folder of your choice:
Move the app.config file to a custom path
Access App.config in a location other than binary

+5


source






More articles:


All Articles