AppDomain.BaseDirectory incorrect for debugging

Add-in Express™ Support Service
That's what is more important than anything else

AppDomain.BaseDirectory incorrect for debugging
 
Charles Mager


Guest


Hi

This is basically this issue again: https://www.add-in-express.com/forum/read.php?FID=5&TID=12582 but it seems to be locked.

We're having an issue running our Add-in within Visual Studio per the referenced issue. On some PCs it's intermittent and usually solved by re-registering the add-in or just trying again, but on other PCs there doesn't seem to be any way of making it work. On the PCs that are intermittent, it most often manifests when running Word or Excel without debugging (but where the add-in was previously registered via Visual Studio).

If we build our installer and install a release build, I have never seen any problems.

The issue seems to relate to the base directory for the AppDomain:

  • On my PC, which is working (mostly) fine, in OnAddinInitialize I can see that AppDomain.BaseDirectory is "C:\dev\<our addin path>\bin\Debug\".
  • On my colleague's PC, I can see that AppDomain.BaseDirectory is "C:\Program Files (x86)\Microsoft Office\root\Office16\". This is obviously incorrect and explains why we get exceptions thrown for assemblies that cannot be resolved. To try and resolve, he has re-installed Windows, installed VS 2015, ADX and Office 2016... and still has the same issue.

Our workaround for now is some horrible conditional compiliation for Debug that attaches a handler to AppDomain.CurrentDomain.AssemblyResolve to ensure we resolve in the right place.

Any thoughts on what might cause ADX to be providing the wrong base directory? Unfortunately I'm going to struggle to give you anything to reproduce as I can't reliably reproduce the issue.
Posted 09 Dec, 2015 11:06:54 Top
Andrei Smolin


Add-in Express team


Posts: 19138
Joined: 2006-05-11
Hello Charles,

Is there a probability that the add-in was a) registered from the IDE and then b) you installed it? If so, uninstall the add-in, unregister it from the IDE, start the host application to make sure there's no traces of your add-in, close the host application, then register or install the add-in.


Andrei Smolin
Add-in Express Team Leader
Posted 10 Dec, 2015 05:14:20 Top
Charles Mager


Guest


Hi Andrei

I think we've tried most combinations of this with no joy. We've definitely been in the position where Word opens - no add-in loaded. We then register via the IDE and get this issue. Is there anywhere specific in the registry we should look to check it's all uninstalled properly? If it makes any difference, it's registered with 'privileges=admin`.
Posted 10 Dec, 2015 05:21:04 Top
Andrei Smolin


Add-in Express team


Posts: 19138
Joined: 2006-05-11
Charles,

#1. Is there a probability that the add-in was registered from the IDE and then installed?
#2. Is there a probability that the add-in was registered on the per-user basis and on the per-machine basis at the same time?

The registry keys are described in section Locating COM add-ins in the registry at https://www.add-in-express.com/docs/net-deploying-addins.php#load.


Andrei Smolin
Add-in Express Team Leader
Posted 10 Dec, 2015 07:02:12 Top
Charles Mager


Guest


Hi Andrei

I guess both are possible. Our installer installs using /install="[INSTALLFOLDER]$(var.Addin.TargetFileName)" /privileges=admin /returnExitCode=false. How do I know how the IDE installs the add-in? How would this affect the loading?

For example, I was working this morning and everything was debugging fine. I made one change, hit F5 and I get this problem until I re-register the add-in via the IDE. Is there any way of finding out how the IDE is registering? What command does it execute? If it helps, our manifest includes privileges=administrator.
Posted 14 Dec, 2015 07:19:45 Top
Andrei Smolin


Add-in Express team


Posts: 19138
Joined: 2006-05-11
Hello Charles,

When you register the add-in, the add-in location is written to the registry. When you start the host application, it loads the add-in from that location. Now imagine that you install the add-in, then modify the add-in project (say, you might add a new Ribbon button to the UI of your add-in) and press {F5} in the IDE. This starts the add-in from the installation folder, not from the folder where the current add-in version is located. As a result, you don't see the newly created Ribbon button. Then you register the add-in from the IDE and press {F5}; this loads the add-in from the output folder of your project.

You need to have the add-in either registered from the IDE or installed. To solve this issue you need to uninstall the add-in, unregister it, start the host application to make sure there're no traces of the add-in and, if you need to debug the add-in, register the add-in project from the IDE.

The above described the issue related to installing and registering a per-machine add-in simultaneously.

If, in addition to the above, you modified the RegisterForAllUsers property of the add-in module, you need to uninstall the add-in, unregister it from the IDE, set the opposite value to the RegisterForAllUsers property, unregister the add-in project, create a new setup project following the corresponding section below, install the add-in, uninstall it, set RegisterForAllUsers as required, create (or modify) the setup project following the other section from the manual and continue developing the add-in.

The sections from the manual that you need to follow are:
- Deploying a per-user Office extension via an MSI installer
- Deploying a per-machine Office extension via an MSI installer

Charles Mager writes:
Is there any way of finding out how the IDE is registering?


The only difference from registering via adxregistrator.exe is the way, it registers a per-user add-in: adxregistrator creates "ProgId" and "CLSID" keys for a per-user add-in under HKCU\Software\Classes, while when registering from the IDE, these keys are created under HKLM\Software\Classes. This is done in this way due to the specific way, Windows loads per-user COM objects for an administrator user running under elevated privileges. The "ProgId" and "CLSID" keys are described in section Locating COM Add-ins in the Registry.


Andrei Smolin
Add-in Express Team Leader
Posted 14 Dec, 2015 09:57:25 Top
Charles Mager


Guest


Thanks Andrei - this looks very helpful, we'll do some investigation.
Posted 14 Dec, 2015 10:00:51 Top
Andrei Smolin


Add-in Express team


Posts: 19138
Joined: 2006-05-11
You are welcome.


Andrei Smolin
Add-in Express Team Leader
Posted 15 Dec, 2015 04:31:14 Top