Cannot load add in with external references on PDM admin tool

Hello All.

I’m developing a PDM Add-in which will manipulate PDF’s in certain ways. To accomplish so, the add in references Itext7 library via its NuGet package.

The problem: I cannot deploy the add in via Administration tool using the “New Add in” command as some iText7 DLLs fail to register. If i ommit the faulty DLLs, Add-in will run and break on some exceptions, all related to a not found reference (due to Itext7’s DLL’s not registering as a whole).

When trying to add all DLLs in the "New Add in " dialog, i get this:

1

To rule out any Itext7 compatibility issues, i ran the add in in debug mode and it works as expected.

Here you will find a slimmed down version of the add in

PowertrainFSAE47/EPDMevents: Solidworks PDM Add In (github.com)

This demo works this way: Right click on a file in the vault, then “PDF MERGE”. Add in will then create a PDF on the same directory with the same name as the origin file, with the phrase “This is a PDF generation test!” written inside it.

I’ve contacted my VAR already and i’m waiting for a decent response, which i think won’t happen at all.

Best regards!

Angelo.

1 Like

This is the best thing I can recommend as far as troubleshooting add-in issues.

Check this: Fix 'Class ID could not be found in the registry' PDM add-in error

Hello Artem

I’ve found that article before, it was the only one which matched when searching on google. Since that reference is surely required, it looks like i will need to give AppDomain::AssemblyResolve a shot, altough i’m unsure on how to do that right now, i’ll read the documentation and keep you posted.

Thank you all!

Angelo.

Thanks for posting. Will debug this soon.

I think I have some what of a working solution.

Check the pull request I created here: https://github.com/PowertrainFSAE47/EPDMevents/pull/1

The issue comes from your references. I’m not so sure but I feel that they contain some COM exposed types that PDM attempts to register and fails. The solution here is to defer the assemblies resolution to the GetAddInInfo method and mark them as Copy Local to false.

Basically the solution goes like follow:

  • Mark all the problematic references as Copy Local to false.
  • Archive all of those assemblies into a zip archive so PDM does not attempt to inspect them for COM types. This will be loaded into the vault when you add the add-in.
  • Include the archive in the solution. Here, I’m calling com.
  • Mark the archive as content and make always copy = true in its properties.
  • Extract the archive zip and load the assemblies using System.Reflection.Assembly.LoadFrom in GetAddInfo (See code) - Can refactored so you don’t extract the archive every single time GetAddInfo gets invoked.
  • Load your add-in again, this time, you only have 3 files to load including a zip archive.

image

Advice:
Start using https://www.nuget.org/packages/BlueByte.SOLIDWORKS.PDMProfessional.Interops/ for your sw pdm pias. Make sure they are marked as embed interop types = false.
Take a look at : https://github.com/BlueByteSystemsInc/BlueByte.SOLIDWORKS.PDMAddInFramework
This repo is a productivity framework for PDM I’m working on.
start using packages that are 100% .NET framework so you don’t have to do this

1 Like

Amen, you were great mate, i wholeheartedly appreciate this. My VAR has been tossing it for an entire month on this and you did it like it’s magic. And we pay them top dollar to do nothing!

I’m going to test it tomorrow and also will try to integrate other PDF framework instead of itext7, or maybe devise a way to offload this thru an external call to a wrapper or something along these lines.

I don’t have a lot of experience with the Add In side of solidworks API (maybe a year) and i find PDM API the trickiest, mainly due to COM shenanigans. I’ve even managed to connect xbox controllers for model manipulation on the vanilla SW API during a not so busy morning, but debugging and running things over the PDM api is certainly a challenge.

Will keep you posted!