Rubberduck: COM Exception thrown

[galeforce7]

Rubberduck version information
Rubberduck version 2.5.0.5244 loading:
Operating System: Microsoft Windows NT 10.0.14393.0 x64
Host Product: Microsoft Office x86
Host Version: 16.0.12527.20880
Host Executable: MSACCESS.EXE;

Description
We are in the processes of moving our Access to a Remote Desktop Services model with all Access applications centralized on a remote server. Through this model I have no access to setting up or configuring and have to rely on our technology team to so this work. RubberDuck was installed and a file to register the application components was created to register RubberDuck with my Access in accordance to the installation page. Unfortunately, when I run RubberDuck Refresh in this environment, I receive a COM Exception (see attachment).

We are currently running this in parallel with my laptop installation (i.e. MS Access 2010 with RubberDuck 2.4.1.4892) and I have no problem doing a RubberDuck Refresh.

To Reproduce

1. Launch MS Access on the Remote Server
2. Open the Visual Basic Editor
3. From the menu Rubberduck->Refresh

Expected behavior
I expect RubberDuck to complete the refresh and load the Code Explorer with the project components.

Logfile
RubberduckLog.txt

[Imh0t3b]

Hi,

I'm not an expert on debug here, but as your issue is 5 days old, I'll try.

Exception is thrown by ExportAsSourceFile what exports your code to a textfile that is then parsed (if I got that correct). As you use RDS I assume a problem with the path RD wants to store that files and that is %LocalAppData%\temp\Rubberduck. That path needs to be writeable on RDS!
General advice is to always use the newest RD version, as they usually have lots of improvements. E.g. one new feature is version check on startup. So try newest version and report if still errors. If so check windows event logs for denied write to some temp folder.

[retailcoder]

@Imh0t3b thanks for that reply! You are correct, this should be a permission issue.

[Imh0t3b]

@retailcoder do we handle that as user misconfig (as we have a check for folder exists, but not for is writeable) or should we implement a test for is writeable and use a different folder (e.g. Roaming\temp) if not writeable? I would vote for message on startup to fix that issue and close RD.

[retailcoder]

Alternatively, I'm guessing we could prompt the user to supply a folder they have write access to, so that the parser still has a place to export the code files... we should make that folder configurable.

[Imh0t3b]

Difficulty level of checking write access and showing a file-dialog > difficulty-01-duckling? Maybe a challange for me ( at time I'm stuck on listview TextWrapping #5013)

[Vogel612]

@Imh0t3b the core problem is that we might be using that path in a hard-coded way in multiple places. That makes the issue a bit more complex than just checking write-access and getting a new path.

It's not necessarily more difficult, but definitely more work than it might seem at first.

[Imh0t3b]

@Vogel612 more complicated than replacing Path.GetTempPath() with a method that checks the path and requests a new one if not writeable in `RUBBERDUCK_TEMP_PATH https://github.com/rubberduck-vba/Rubberduck/blob/8695c05e91cbd9f6ba9dd324c523ac89cf33b331/Rubberduck.Resources/ApplicationConstants.cs#L6-L11

[bclothier]

FWIW, we have the issue #4533 & #4794 because that would be the best place to handle filesystem problems, including lack of write permission & taking configuration values. That might need to expand the existing PersistencePathProvider to provide for temporary path.

It's a bit odd that there can be permission issues with GetTempPath, since in theory, Windows guarantees that the temp are always write-able but we'll need to accommodate the case where that assumption is violated a bit more gracefully than throwing a COM exception.

[Vogel612]

We're not using GetTempPath... the source is exported through the TempSourceFileHandler. For the Office-Attached VBE, the implementation is in Rubberduck.VBEditor.VBA and looks as follows:

https://github.com/rubberduck-vba/Rubberduck/blob/8695c05e91cbd9f6ba9dd324c523ac89cf33b331/Rubberduck.VBEditor.VBA/TempSourceFileHandler.cs#L13-L17

At this point we need to check all usages of RUBBERDUCK_TEMP_PATH for this issue and replace it with a lazily initialized Path that can be defined in the settings and possibly prompts the user if writing permissions are not a thing at that path.

[bclothier]

That's why I linked the issues; IMPOV, those components have no business fiddling with System.IO; that needs to be delegated to a class dedicated to handling the filesystem access in an uniform manner.

BTW, that does actually use GetTempPath:
https://github.com/rubberduck-vba/Rubberduck/blob/23039cc5ecda48fb1b8acd4da0d982c9149dab54/Rubberduck.Resources/ApplicationConstants.cs#L10

[Imh0t3b]

Seems out of scope for me then ;( But of xourse I don'tneed to worry about no more suitable isues avainle to me. I'll check german translations for completeness and dig somewhat deper into RDs structure.

[galeforce7]

As I mentioned, our IT department has placed Access on a server and I have to use remote connection to the box. They have it configured so that I very few permissions outside of the folder where I can launch MS Access. I will check on Monday when the IT folks are in the office to see what 'local' folders on the remote server I would have permissions.

[adthorn]

The temp path is writeable to the user profile disk for the Access 365 RemoteApp.

From the Error Log:
at Rubberduck.VBEditor.VBA.TempSourceFileHandler.Read(IVBComponent component) in C:\projects\rubberduck\Rubberduck.VBEditor.VBATempSourceFileHandler.cs:line 52

C:\projects does not exist anywhere on the servers hosting Access 365 and RD.

[MDoerner]

The path you see in the exception is the source path at the time of compilation; it has nothing to do with the export path.
This has confused quite a few people already.

[retailcoder]

I think we could fine-tune the NLog config to, instead of just dumping exception.ToString into the logs (which includes the build paths, source file names, and line numbers from the .pdb debug info), to strip the string C:\projects\rubberduck\ from stack traces getting logged. Or we could just stop shipping the .pdb, but then we'd also lose the line numbers and the source code file name.

[retailcoder]

On the bright side, the C:\projects\rubberduck path lives on AppVeyor build servers. Before CI was setup, stack traces in the logs might have looked like C:\Dev\GitHub\Rubberduck\Rubberduck.Main\bin\Release\SomeSourceFile.cs if I had made the build on my machine, or C:\Users\Someone\My Documents\GitHub\Rubberduck\... if someone else did it. At least we get consistent non-existing paths now!

[galeforce7]

Folks, I haven't forgotten about this,. Just waiting for our IT dept. to upgrade the RubberDuckVBA to the latest version.

[galeforce7]

Everyone,

Thanks for all the input. The Access Server team updated the farm last week to 2.5.1.5557 and everything appears to be working correctly. Not sure if this is just from being reinstalled or if you made changes, but thanks for all of your help.