Accessibility Issue with .NET Assembly on NFS Folder RRS feed

  • Question

  • I have a VS 2005 .NET assembly (C# Windows class library) that I have placed on a NFS folder.  I have made it COM visible so that other developers can use it from Access/Excel VBA, if they desire.  Another developer has successfully registered the assembly on their client machine using regasm, and has successfully loaded it from Access VBA.  The main form of the library successfully displays, and much of the functionality is available.  However, when the assembly attempts to parse some XML files, it provides the following error:

    Access to the temp directory is denied.  Identity '[domain]/[userid]' under which XmlSerializer is running does not have sufficient permission to access the temp directory.  CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile.  Use Path.GetTempPath() API to find out the temp directory location.

    I've done as suggested and looked at the location of the temp folder by using Path.GetTempPaht() API.  I've ensured that the user has proper access priveleges to this temp folder (C:\Documents and Settings\[userid]\Local Settings\Temp).  I've also gone as far as to copy the assembly to the client local hard drive and register it from this location.  I still get the same error no matter what I try.

    I've also evaluated the assembly through the .NET Configuration shows that the permissions granted to this assembly are "Unrestricted". 

    I'm not sure what to do next.  Any help will be greatly appreciated.
    Tuesday, May 5, 2009 8:31 PM


  • It is not complaining about your assembly, it is failing when it tries to generate the XML serializer assembly.  That one is created on-the-fly with CodeDom using the temporary path to store the .dll file.  Consider the possibility that the client code is not running with the user's account so has a diffent path for temporary files.

    One possible workaround is to pre-compile the serialization assembly with the Sgen.exe tool .  Ask questions about it in the XML forum.
    Hans Passant.
    • Marked as answer by w00kie Tuesday, May 5, 2009 9:00 PM
    • Unmarked as answer by w00kie Tuesday, May 5, 2009 9:00 PM
    • Marked as answer by w00kie Tuesday, May 5, 2009 9:02 PM
    Tuesday, May 5, 2009 8:55 PM