Hello Peter, i greatly appreciate your help. At this moment, the only machine that runs my add-in is the development machine. As i said before, i tried to use Visual Studio Setup Projects (herein VSSP) unsucessfully. Analyzing my dev machine registry, i saw some important things:
1- All my public classes were registered under “Classes” folder on HKEY_LOCAL_MACHINE_SOFTWARE/Classes.
Each class gets a CLSID apparently assigned by Visual Studio on compile time. I didn’t use an add in installer on this host/dev machine. I just used Luke’s add in registering tool and each time i compile, it reloads and works flawlessly.
2- VSSP doesn’t register my classes for COM Interop although ive marked it explicitly, as shown:
Since VSSP didn’t work at all, i decide to try advanced installer as you said, my registry page is this one:
This is my build/resources list:
I find it rather weird on it including all microsoft dependencies. Smelly.
I have also set my output class to be COM interop registered, as follows:
All my classes are internal, bar MyAddInControl, MyTaskPaneUI and SolidDNA’s which are public This is taken straight from Luke’s WPF Addin template.
After installing with the advanced installer built installer, Registry shows the solidworks/addins key and all public classes registered with a CLSID under HKEY_LOCAL_MACHINE_SOFTWARE/Classes.
SolidWorks doesn’t give a d*** and add in simply wont load, path for the DLL is nowhere to be found, as shown here on the red square
Sorry for the long post, this is driving me to the edge, absurdly complex procedure for a trivial thing.