Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"unrecoverable error" when running RunnerTests & SampleTests #28

Open
vinnividivicci opened this issue Mar 11, 2015 · 4 comments
Open

Comments

@vinnividivicci
Copy link

When running the RunnerTests using a compiled-from-source version of the RevitTestFrameworkGUI.exe I keep getting this error (running everything from 2015 branch and targeting revit 2015):
"An unrecoverable error has occurred"
screenshot_031115_040448_pm

I'm baffled because compilation runs fine...

@ikeough
Copy link
Contributor

ikeough commented Mar 11, 2015

Hi @vinnividivicci. That error usually happens if an addin that you are attempting to use during testing is not available. There is one good way to check. When this error pops up, find the log file for the running session of Revit, which will be located in RTF's working directory. That log file will tell you what went wrong. The log file is located in RTF's working directory because when running Revit with journals, the logs are written to the same location as the journal file. You have to look at the log file before you dismiss this warning because RTF will cleanup the log file after the test is finished.

Also, when running in journal mode, Revit will not automatically initialize all the addins on your machine. It will only initialize the ones that have .addin files in the same folder as the journal. For this reason, RTF copies over all of your .addin files to its working directory at run-time to simulate the same revit environment which you would have if you were running Revit normally.

@vinnividivicci
Copy link
Author

@ikeough Thanks for the thorough explanation, I got it working now. In my case the Add-ins that were causing the issues were Add-ins that had DLLs in the same folder as the .addin file, and since those folders don't get copied automatically, it was crashing...

So I've got 2 suggestions (which I'm willing to code myself and add to the repository):

  1. Would it be safe to just copy over ANYTHING inside the add-in root folders in order to prevent this basic error? I mean copy the entire contents of C:\ProgramData\Autodesk\Revit\Addins\2015 over to the working directory? Obviously while keeping track of them in order for the cleanup to work.

  2. I noticed that it's only copying over the Add-ins found in the "AllUsers" location C:\ProgramData\Autodesk\Revit\Addins\2015 but could we also include the Add-ins found in the User-specific location %APPDATA%\Autodesk\Revit\Addins\2015 by default?

I'm really interested in improving RTF since I really think Revit and Revit Add-ins need to use TDD more 😄

@ikeough
Copy link
Contributor

ikeough commented Mar 12, 2015

@vinnividivicci Good to hear you got it working. What kind of dlls do you have in the addins folder? I've never seen dlls in the addins folder so I didn't think to copy them over. I think copying everything over is probably OK so long as you keep track and cleanup. There's already a lot of stuff to cleanup. I'm wondering if we don't want to make a temp folder and copy everything into that folder and run from there. Then it's just disposing of one folder.

@vinnividivicci
Copy link
Author

@ikeough That might be a cleaner solution moving forward. However...

There is additional complexity to this problem... Some .addin files point to DLLs in relative paths that are outside of the %APPDATA%\Autodesk\Revit\Addins\2015 folder and others that are in subfolders.

Examples:

  • the Unifi Add-in points to ..\Unifi\InviewLabs.Unifi.Revit2015.dll
  • the ADN Duct Fitting add-in points to .\ADNPlugin-DuctFittingTableViewer.bundle\Contents\ADNPlugin-RMEAshraeViewer.dll

So I'm thinking it may just be simpler to not support Add-ins who's DLL path starts with . for now and let each developer customize their own tests to work.

BTW, is there a best-practice guide out there about where to put Add-in DLLs? It seems to me like dumping them in the Addins folder or in user data is a lazy solution... I install all my Add-ins into Program Files ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants