Add in installer for solidworks add ins

[FSAE47]

Hello all.

I’ve developed my first task pane add in based on Luke’s solidDNA. Installation steps for this are as follows:

1- Run db creation script on server (manually)
2- run Luke’s Add in installer tool on each client in order to regasm binaries.

This is sort of too much manual work to deploy an addin to a internal customer who knows jack about anything. Is there any preferred or typical installer generation tool that can be used to automate this and is often used by add in developers?

I’m learning innotools and Visual Studio Installer projects, but would be nice to know what do you guys usually run.

Regards
Angelo

[AmenJlili]

Check out this video by @artem Creating installer for SOLIDWORKS add-in with Visual Studio Installer (VSI) - YouTube

[FSAE47]

Hello Amen. Greatly appreciate it, i’ve managed to build an installer from Artem’s video.

Although the installer worked as expected, at first i had some sort of “clash” between task pane add ins. SolidWorks did think that my add in was Xometry’s instant quote and didn’t load it.

I uninstalled instant quote, checked the register to see if GUIDs were mangled somehow, it looked ok. Uninstalled my add in, reinstalled and now SW recognizes it in the add-ins menu, but without a path for the DLL. So it won’t load when checked.

All add-ins listed show the DLL path, bar mine.

I don’t know if something else has to be done on the solidDNA side of things neither.

Edit: I ran solidDNA’s add in installing tool and it managed to register the dll path. I’m missing something obvious here

Angelo

[AmenJlili]

Were you able to solve this issue?

[FSAE47]

Not yet. There are differences in how SolidDNA registers or “connects” files to solidworks which i think clashes with VS Installer project’s way.

I’m trying to find out what is it. In the meantime, i’m installing with Luke’s tool

[BigCrazyAl]

I actually ran into this yesterday. I’m using SolidDNA as well and modified it somewhat to include features that I felt it was missing. I’ve been using Regasm to “install” the DLL on client machines but just recently started looking into an installer.

After quite a bit of digging, the GUID that I created and placed in my add in is not the GUID that is related to the dll (in the registry) when using Regasm to install it. It’s odd and I can’t find any reference to the GUID that it is using. So, until I solve that problem, I’ll continue to have the DLL registered manually.

I know @PeterBrinkhuis has used SolidDna extensively and may have some additional insights.

[PeterBrinkhuis]

Thanks for tagging @BigCrazyAl. I have actually forked the project last week so I could:

• Apply my fixes that were hanging in PRs
• Make it able to run multiple add-ins at the same time
• Remove the ability to run in a separate app domain (I didn’t need it and it clashed with the multiple add-in feature)

You can get it here: NuGet Gallery | CADBooster.SolidDna 2.9.0
I might get these changes merged back into Luke’s version, he was open to that idea.

That being said, regasm and Luke’s installer tool aren’t meant to be used in production. You should create an installer (I use Advanced Installer) that registers your public classes + the add-in.

Register public classes
My installer registers all public classes in my add-in DLL. Only my add-in, plugin and TaskPaneWindow classes are public, the rest is internal. COM registration is only enabled for this one DLL. The only hardcoded GUID I have is on my add-in class, that’s the one that needs to stay the same between updates:

Register your add-in within the SolidWorks register
I add these registry keys for Drew so SolidWorks knows which class to instantiate during startup. Adding this key is why you need admin privileges to install add-ins:

Besides that, there is a ProgId string in the TaskPaneHost.cs code-behind that needs to be unique for your add-in.

[FSAE47]

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.

[PeterBrinkhuis]

Your issue seems to be Registry related, not at all Solidworks related.

The CLSIDs of public classes are registered when you set Synchronization to enabled. Each public class should then appear in HKEY_CLASSES_ROOT. The top item CADBooster.First is the TaskPaneHost and uses the ProgID you set there. The three after that are my public classes.

But even Advanced Installer does not run the code in classes marked as COM Visible / ComRegistration, so that’s why we need to add the GUID of the add-in to the Solidworks folder. The GUID you add to the add-ins folder in the registry is used to look up the add-in class. It should match the GUID on MyAddInIntegration.

I just looked up the WPF template you used, and the add-in class does not have a GUID attribute. Please add one, like this and add use the same GUID in the registry in the Solidworks folder.

So please check this:

• Verify that each public class is under HKEY_CLASSES_ROOT
• Verify that your add-in has a GUID “19BC…” or add one so it always stays the same.
• Use the add-in GUID in the SW registry folder.

[BigCrazyAl]

@PeterBrinkhuis

I just looked up the WPF template you used, and the add-in class does not have a GUID attribute. Please add one, like this and add use the same GUID in the registry in the Solidworks folder.

This was actually a big part of the issue that I was having. I placed my projects GUID in AddInIntegration class and that solved my biggest issue.

My other issue was caused by the out-of-box installer failing to create/delete registry entries every time it’s run, so I went with the Wix library and finally got that working too. It seems more robust.

Installers are a whole different animal…

Now, to figure out how to check for updates and prompt the user to install them. However, I don’t want to derail the thread so I’ll work that out on the side since it’s much less time sensitive at the moment.

[PeterBrinkhuis]

Awesome. Once I saw that GUID missing from the template, I also thought that would be the issue. I think I’ll add it to the template.

Advanced Installer has a good updater. You start a new thread on startup with a delay, it checks your website for a txt file and triggers an update message when it finds one.

[AmenJlili]

Use async await to spin a new thread.

[BigCrazyAl]

@AmenJlili

Use async await to spin a new thread

Got it working! Yes, it’s on another thread so loading the add-in isn’t significantly slowed. I just keep updating the MSI file in PDM and it will prompt the user to update.

[AmenJlili]

Sweet! Is that inferno?

[AmenJlili]

Make sure you get the handle of the splash window so you can print the message box on top. There will be times where the message box prints below the splash and will cause people to think sw is not responsive.

[FSAE47]

Hello all, and specially Peter.

You were spot on!. That solved my problems and now the add in installs flawlessly. I’ve now to guess how to create a database from the installer but that surely is another topic on its own. Like BigCrazyAl said, installers are a whole different animal.

Best
Angelo