Describe the bug
Installed using the executable. The .addin manifest is placed in the user profile location and everything runs fine when opening Revit. We customize addin loading via a custom addin where we remove the original .addin manifest and drop it in the user profile if the user enables the addin. When doing this, I'm getting the following error with the latest version (4.7.1-beta2).

To Reproduce
Steps to reproduce the behavior:
Note that if I now leave the .addin manifest as is, then close and re-open Revit, pyRevit will load with no issues.
Expected behavior
pyRevit should load without issues
Screenshots
Please see above.
Desktop (please complete the following information):
That's odd. Do you have the bin/engines/368 and bin/engines/372 directories in the install path?
I'll test this out today. So this issue happened when hot-loading pyRevit while Revit is running.
Hi @eirannejad , yes they are present and yes, when hot-loading pyRevit while Revit is running.

Released 4.7 beta 3 with improvements. Hopefully it fixes this issue. Please test when you get a chance
I used the above method but it still failed
Revit 2019.2
pyRevit_4.7.2 beta 3
see more https://imgur.com/TpjHW97
Would you check please to see if Nett.dll is inside the bin/ path in the installed pyRevit?
Also why is there a need to hot load pyRevit like this?!
Also why is there a need to hot load pyRevit like this?!
Because it failed if I didn't do that. So let's try it
https://i.imgur.com/098RjPa.png
So odd.
@CuongVTC Try uninstalling pyRevit and install it again
@htlcnn thanks,
I have reinstalled it several times
Also why is there a need to hot load pyRevit like this?!
We have been doing this with all our addins for the last 3 years. Users have the option to load for the current session only or always. Only a couple fail and have to be set to "always" (the .addin manifest has to be in place before Revit starts or the addin fails to load properly). We do this for two prime reasons: loading speed when launching Revit and stability in general. We have tons of addins and it was slowing loading times considerably, especially on Citrix. Considering addins are only used occasionally, we needed a more "on-demand" process for loading them. This also gave us an entry point to see which addins are the most popular (we log loading data and visualize on a web portal). The second factor is stability: we were running into several issues where some addins caused file corruptions or instability, so by limiting what loads automatically when users are working, reduced the instance of these issues. Thanks.
BTW beta3 resolved the issue @eirannejad :) Thanks a ton as always!
@CuongVTC I can not replicate the issue here on my machine. Not sure why this is happening. It's got something to do with the assembly resolution not being able to find Nett.dll
Maybe conflict with another addon
@dbaldacchino Awesome! Phewww 馃槄!