System.AccessViolation when using the MSSCCI-API

[PhilS]

Hi Guys!

We're experiencing a problem on one computer when using the VaultIDE.dll via the MSSCCI-API.
We can successfully call SccRunScc, but when our code calls SccGetProjPath the Vault client fails with an System.AccessViolation.
(A simple programming error can be ruled out. Our code calling the API is installed on hundreds of computers (dozens with Vault) and this is the first time we encounter this error.)

This applies to Vault Classic 10 and VaultPro 10.
The Vault client applications run without error.

Questions:
What can be a possible causes for this error? - Any ideas?
Can logging be enabled for the Vault client in this scenario to get further info on the cause of the error?

Best regards,
Philipp

[jclausius]

Is the process loading the VaultIDE.dll a .NET Framework based process? One of the requirements of VaultIDE.dll is that the calling process *must* be a .NET Framework based application OR a compiled (using something like a C-runtime) application, but the .NET Framework installed (as the Vault IDE.dll will self-host the .NET Framework)

Is it possible the other machines in which it does work has different versions of .NET Framework installed than where the System.AccessViolation error is seen?

You can enable logging within your IDE, by modifying or copying / renaming a .NET configuration (.config) file. For example, for a normal non .NET based application, you could take VaultGUIClient.exe.config, copy it to the directory where <your_ide_binary_here>.exe exists and rename it to "<your_ide_binary_here>.exe.config". Then within the file, you can edit the various logfile entries to enable logging for all Vault related classes.

See the "Enabling Logging - Editing The Configuration File" section in this KB article for logging options - viewtopic.php?t=1534

[PhilS]

Is the process loading the VaultIDE.dll a .NET Framework based process?

Yes, it is. It is a .Net COM add-in hosted in Microsoft Access.

Is it possible the other machines in which it does work has different versions of .NET Framework installed than where the System.AccessViolation error is seen?

I cannot answer this to the last detail.
The runtime version used by our add-in was 4.0.30319.42000 on all machines involved/checked.
I know the machine experiencing the problem has only the .Net Framework 4.x installed.
I guess at the clients site other machines, which have no problem, also have only .Net Framework 4.x installed.
All of our own machines, which have no problem, have .Net 4.x and 2.0 installed.

I will try to enable logging tomorrow and hope it will reveal some helpful information.

[jclausius]

If only .NET 4.0 is installed, it could be you need to configure the Vault IDE plugin to use .NET 4.0 - since by default it will try to host a .NET 2.0 environment, and that isn't installed. Installing .NET 2.0 Framework would be the easiest thing to try, but that is sometimes not practical. For those scenarios, see this KB article for setting the Vault IDE.dll to use a specific .NET version using "CLRVersions" hive in the registry - viewtopic.php?t=15034

In your case, my guess is the same type of configuration needs to be applied for Access where .NET 2.0 Framework is NOT installed Note, I believe only the first post of setting the binary executable path / .NET version is needed. Also note, I think the .NET version is still "v4.0.30319" even for .NET 4.7 framework, but not 100%. Do you know what version of .NET Framework 4 is installed?

Finally, only try the info in the first post for now (Registry for "CLRVersions"). The instructions in the entire KB article are about choosing a Framework for a specific version of .NET (.NET 2.0), but the registry changes going back to Vault 6 overrides those instructions.

[PhilS]

Installing .NET 2.0 Framework would be the easiest thing to try, but that is sometimes not practical.

Jeff, thanks a lot! Installing .Net 2.0 indeed fixed the problem on the clients machine.

I will investigate your other references because with many clients installing an additional, slightly obsolete, .Net Fx will not be possible. - However, that's much lower priority for us now that the pressing issue is resolved.

Thank you for your excellent support!