PDM, ChangeState() call will cause SOLIDWORKS PDM error dialog popup "Failed to register COM DLL..."

[bnemec]

I cannot make sense of this behavior so I'm not sure how to ask for help. While debugging, I'm calling ChangeState3 from an IEdmFile13. During that process something is causing PDM to try to register our other task add-in, again. I say again because the task add-in has already been registered. The program I'm debugging has nothing to do with the task add-in; they're not even in the same solution and I'm not using any of the my libraries (other classes) from the add-in solution. The call does succeed though because the file does change state. I did this a bunch of times.

The dialog I get is:

followed by this one"

image.png (7.68 KiB) Viewed 4737 times

If you look closely you can see it has a '3' at the end of the GUID number because it downloaded the add-in files again when I debug my project (that has nothing to do with pdm task add-in project)

I can change state through the vault view manually just fine.

This is a console app, not windows Form.

The transition(s) I'm calling in code do have some actions to set variables, but no execute task actions so they are not calling our task add-in.

I thought there was something wrong with my SW and PDM installation on my development machine (a VBox guest) so I did a clean uninstall and reinstalled SW and PDM from our admin image, like normal. Of course added the vault view back etc.
After doing that I noticed that my Projects' reference to the EPDM.Interop.epdm was broken. Turns out previous installation of PDM was not in the same place as it is now in the C:\ProgramFiles\ directory, so I updated the reference to the new installation location and rebuilt. I don't know if that has anything to do with it.

After fresh installation same behavior.

Just guessing now, I rebuilt my home brew task add-in project and updated the add-in files through the PDM Admin Tool. Then exited from pdm and restarted explorer.exe on my development machine. That made no difference again.

I cannot understand why calling ChangeState3 while debugging one project is causing PDM to try to register some other task add-in that's already registered. Clearly I have something screwed up but I'm lost as to what or how to find it.


Side note, I tried ChangeState() (not 2 or 3) but that always throws an exception that the state ID doesn't exist, whether I pass the state id as an int or the name as a string. I know that state id and name are good because they are in the dbo.Status table with Enabled = 1. ChangeState3 handles the state id just fine. Well, except PDM throws this darned error. There's about 50k part numbers in my list to work through and using the API Search call for each one is slow so I really don't want to sit here and click "OK" the whole time this runs.

I don't recall if I ever tried simply calling ChangeState3 all by itself in a test program. I'll go write a simple console app for that to see if it is the same.

about ready to quit and start

I'm open to any suggestions at this point.

[bnemec]

This is about as simple as I can come up with

Code: Select all

using EPDM.Interop.epdm;

namespace PDM_test
{
  class Program
  {
    private static IEdmVault8 vault;
    private const string VLT_NAME = "CleanupVault";

    private static int windHandle = 0;


    static void Main(string[] args)
    {

      //initialize global vault stuff
      windHandle = (int)System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle;

      vault = (IEdmVault8)new EdmVault5();
      //sign into vault
      if (!vault.IsLoggedIn)
      {
        vault.LoginAuto(VLT_NAME, windHandle);
      }

      IEdmFile13 edmFile = null;
      IEdmFolder5 parentFolder = default(IEdmFolder5);

      // edmFile = (IEdmFile13)vault.GetObject(EdmObjectType.EdmObject_File, theFile.ID);
      edmFile = (IEdmFile13)vault.GetFileFromPath(@"C:\CleanupVault\CAD_Data\0004\0004601.sldprt", out parentFolder);

      edmFile.ChangeState3(191, "To Obsolete", parentFolder.ID, "testing ChangeState3()", windHandle, 0, "myplaintextpassword");

    }
  }
}

When I ran it the test file changed state and I got those same error dialogs about failing to register. But this time instead of 3 it was 5 in the directory name.

Then I ran it again but updated the destination state id to the next state in workflow and looked up a transition id from sql for the transition id parameter. The file changed state and I the dll failed to register.

It does not seem to be tied to state (source or destination), the transition, or the file.

I quit for today. Try again tomorrow...

[Diaval]

What PDM version are you using?

Does your system have an antivirus running? Trend Micro real-time monitoring has a tendency to grabbing the add-in as soon as it is downloaded to the client and causes a sharing violation when PDM tries to access the file.

To investigate this, you can run Process Monitor and filter for sharing violation to see if explorer is experiencing any sharing violation trying to load any add-in.

See SPR 1220846

[bnemec]

What PDM version are you using?

Does your system have an antivirus running? Trend Micro real-time monitoring has a tendency to grabbing the add-in as soon as it is downloaded to the client and causes a sharing violation when PDM tries to access the file.

To investigate this, you can run Process Monitor and filter for sharing violation to see if explorer is experiencing any sharing violation trying to load any add-in.

See SPR 1220846

Thank you Diaval, glad to hear from you.

PDM version 2019 most everything at SP4 but IIRC there's some component that's at SP5, maybe the database server service. If possibly relevant I can get details.

I set up the VM and I did not in stall any AV software, but the Microsoft AV is on. I'll turn it off and try again. This VM isn't on our domain, I'm logging in as local user. But I access network shares and vault by domain\user login and as far as I know that has not cause any problems; I could be missing then though. I built and debugged our dxf and pdf task add-in on this VM, I still use it to initiate the tasks now and then. It is not a task host.

I have used Process Monitor a tiny bit in the recent past, I will get that going and look for sharing violation.

[Diaval]

PDM version 2019 most everything at SP4 but IIRC there's some component that's at SP5, maybe the database server service. If possibly relevant I can get details.

This is enough info. It shouldn't matter to have one component at SP5 with the rest at SP4.

I set up the VM and I did not in stall any AV software, but the Microsoft AV is on. I'll turn it off and try again. This VM isn't on our domain, I'm logging in as local user. But I access network shares and vault by domain\user login and as far as I know that has not cause any problems; I could be missing then though. I built and debugged our dxf and pdf task add-in on this VM, I still use it to initiate the tasks now and then. It is not a task host.

I have used Process Monitor a tiny bit in the recent past, I will get that going and look for sharing violation.

Interesting that you are seeing this without an AV other than the Microsoft one setup. The VM sounds like things should be setup ok so it will be interesting if ProcMon shows anything.

[bnemec]

I added just the Result is SHARING VIOLATION filter. These two lines show up before my break point at the very beginning of Main().

When I step through the test program no more events show in Process Monitor even though I still get those dialogs about failing to register.

I'm going to keep working with different filters so see what I can find. I did update the simple test code just to add an if else so it moves the file back and forth between WIP and Review. Both transitions cause same behavior.

[JSculley]

I'm open to any suggestions at this point.

Is there a reason you are using a console app for this instead of creating a PDM add-in? Personally, I have a generic add-in that is available from the right click menu anywhere inside the vault. Whenever I need to create a little utility or test some idea/problem I add a new menu item to execute the code. This add-in is installed as a Debug add-in to keep it separate from the normal add-ins and only visible to me.

Something is causing your system to re-download and re-register the add-ins (installed in the vault) to you local machine, and this process is generating the error message and incrementing the number after the GUID.

Some troubleshooting ideas can be found in S-042947 in the SW Knowledge Base.

[bnemec]

Is there a reason you are using a console app for this instead of creating a PDM add-in? Personally, I have a generic add-in that is available from the right click menu anywhere inside the vault. Whenever I need to create a little utility or test some idea/problem I add a new menu item to execute the code. This add-in is installed as a Debug add-in to keep it separate from the normal add-ins and only visible to me.

Something is causing your system to re-download and re-register the add-ins (installed in the vault) to you local machine, and this process is generating the error message and incrementing the number after the GUID.

Some troubleshooting ideas can be found in S-042947 in the SW Knowledge Base.

You raise a very good question. I've found that usually console apps are simple and straight forward, especially to debug or monitor. That theory is being eroded quickly as I do more in PDM-API.

I have not messed with the Debug_Addins yet. I just read the help page you linked. My eyes crossed from all the adding of add-ins and I wondered, "How many Ins could an add-in add if an add-in could add Ins?"

I was sticking with what I knew (or I thought I knew), just trying to get some data cleaned up so I could get better results of what I'm trying to get done. Many files migrated into vault that are for obs part numbers, using result set from query to the "ERP" Database to get the list of part numbers that are obsolete in ERP and then working that list with EDmSearch to transition several thousand files to obsolete state. But that's not the main goal, I'm supposed to be getting the list of part numbers that have not yet been modeled in Solidworks and prioritize them based on where used popularity of the Solid Edge files. But the old files that should be in obsolete state keep getting in the way, so I thought I could just get them moved. But now it sounds like I need to take time to learn about using the Debug_Addins method because using a console app is not a recommended way to do one-off tasks?

Going to look up the KB solution you mentioned. Thank you.

[bnemec]

Something is causing your system to re-download and re-register the add-ins (installed in the vault) to you local machine, and this process is generating the error message and incrementing the number after the GUID.

I forgot what I came back to post, from ProcessMonitor. Pretty much exactly what you stated.

Just two filters other than the default stuff.

[bnemec]

This site! I spend more time reloading the page than...

It's like the wealth of knowledge is kept locked behind a gate with one gate keeper that all must go through to get any single document at a time. And he's narcoleptic.

But, there's four good articles in there that seem to cover this issue. At least a couple are written by Tor!

I am beginning to see why doing everything (even debugging/running a one off migration/update tool) through the add-in ends up being simpler than a console or form app in the long run.

[bnemec]

Am I using the correct epdm library?

[JSculley]

Am I using the correct epdm library?

image.png

Perhaps not. Per the API Help Instructions:

==============================================
7. Right-click the project name in the Solution Explorer and click Add Reference.

1. Click COM in the left-side panel, click PDMWorks Enterprise 20nn Type Library, and click Add.
==============================================

This is how I add references, and my Properties dialog looks like this:

Note that the Description property says 'PDMWorks Enterprise 2021 Type Library', whereas yours is empty. My file version is 23, which I think would mean that 2019 should be 21, but yours says 22.

[AlexB]

This is the reference that I used when I started building my PDM code.

https://www.codestack.net/solidworks-pd ... g-started/

Interops in .NET
If you are building the application in .NET (C# or VB.NET) you will need to use SOLIDWORKS PDM API interop to access the signatures of API methods.

Framework 4.0 or newer
You need to add the reference to EPDM.Interop.epdm.dll which is located in the installation folder of PDM (usually C:\Program Files\SOLIDWORKS PDM\EPDM.Interop.epdm.dll).

Note, although you can add the reference to EdmInterface.dll (type library) this will generate the Interop.EdmLib.dll which can be used by .NET, however this interop will not have a strong name which may introduce conflicts with other add-ins.

It is recommended to set the Embed Interop Types option to False for the interop otherwise the add-in may misbehave.

Framework 2.0 or older
Newer versions of SOLIDWORKS PDM do not provide the interop compatible with .NET Framework 2.0 or older. So it is required to generate this interop from the type library (EdmInterface.dll).

Either add this reference directly to your project (usually C:\Program Files\SOLIDWORKS PDM\EdmInterface.dll), this will generate the Interop.EdmLib.dll in the bin folder after rebuild which you can reference by other projects.

One thing that I ran into when debugging my code was that testing an add-in that had any code writing debug code to the console cause an error (i.e. Console.WriteLine())
Removing those in the installed add-in allowed it to work fine. I haven't run in to the error you're experiencing so I have no idea if it could be related.

[bnemec]

Perhaps not. Per the API Help Instructions:

==============================================
7. Right-click the project name in the Solution Explorer and click Add Reference.

1. Click COM in the left-side panel, click PDMWorks Enterprise 20nn Type Library, and click Add.
==============================================

This is how I add references, and my Properties dialog looks like this:

image.png

Note that the Description property says 'PDMWorks Enterprise 2021 Type Library', whereas yours is empty. My file version is 23, which I think would mean that 2019 should be 21, but yours says 22.

The more I learn the more I realize how little I know.

Apparently there are two ways to reference PDM API, both mentioned in the help and the differences between them are over my head.

https://help.solidworks.com/2019/Englis ... dmapi.html

https://help.solidworks.com/2019/Englis ... 05d91e#Pg0

From the second link:

Using .NET Framework 4.0 in Stand-alone Applications
If your project uses the .NET Framework 4.0 primary interop assembly provided with SOLIDWORKS PDM Professional:

Reference EPDM.Interop.epdm.dll and EPDM.Interop.EPDMResultCode.dll by:

Right-clicking the project name in the Solution Explorer.

Selecting Add Reference.

Selecting Framework in the left-side panel.

Clicking Browse and navigating to the top folder of your SOLIDWORKS PDM Professional installation.

Locating and selecting EPDM.Interop.epdm.dll.

Clicking Open.

Clicking Add.

Repeat step 4.

Locating and selecting EPDM.Interop.EPDMResultCode.dll.

Repeat steps 6 and 7.

Click Close.

Include the following statements in your code:

VB.NET:
Imports EPDM.Interop.epdm
Imports EPDM.Interop.EPDM.Interop.EPDMResultCode


C#:
using EPDM.Interop.epdm
using EPDM.Interop.EPDMResultCode

EDIT: when looking at your screen shot of refs I realized in my hast I made a bone head mistake of not setting the "Embed Interop Types" to false. I've ran into that problem before and I should know better on that one! I fixed that and ran again. No change.

[bnemec]

S-078435 AppLocker blocking dlls. Looking in the Event Viewer per the pdf in KB there are no events. I'm assuming this is because AppLocker is not turned on.

S-059091 and S-042947 and S-017133 All go into detail concerning how dlls are loaded, esp. 042947. I can't say that I was able to understand 100% of all of them but I am running Process Explorer and per the steps in 059091

When browsing in to a file vault view containing API add-ins, the add-ins will be retrieved from the archive server, extracted to the local appdata folder and automatically registered. See exact details in solution S-042947.

When add-ins are updated, the newer version will be retrieved from the archive server and registered in the local appdata folder.

If the add-ins not loading properly, or you want to find out what version of each DLL is loaded, use the Process Explorer (http://technet.microsoft.com/en-us/sysi ... s/bb896653).


1. Start Process Explorer
2. Select View, Lower pane View, DLLs
3. In the lower pane, enable columns Version and Path
4. Select the Explorer.exe process.

The add-in DLLs will show where they are registered under the local appdata folder. (see attached screenshot S-059091-processExplorerLoadedAddins)
For example:

C:\Users\Tor\AppData\Local\SolidWorks\SolidWorks Enterprise PDM\Plugins\A file vault\{2D002684-5D52-3C8D-B7EB-32C45CFD163D}10

The GUID folder will be dynamic and created when the add-in is cached and registered.

I'm not seeing my add-in loaded at all But if I search on "Handle or DLL substring" I get it. please see screen shot. Showing both the lower pane per the KB article and the search results. Note that if I select a row in the search results I get an error.

I tested again on the development VM machine that I can manually change state with no trouble.

I also tested the PDM_Test.exe simplified app on my host PC and I get the same failure to register error. I did not run process explorer per S-059091 on the host PC yet to confirm same behavior.

I thank you all for you help and input so far. I'd really like to be able to change state in stand alone applications, we have back burner projects that will sync data from other data systems to PDM and those will need to be stand alone apps called by other systems.

Oh, I tried using ChangeState2 just to see, but it thows the same exception that ChangeState does, invalid state ID. I wonder if that has something to do with the problem or if that's expected behavior of the older functions.

I'm done for this week and I'm just about out of Whiskey Blues so I'm going home now.

Hope you all have a great weekend.

[bnemec]

In case anyone cares, I was finally able to try the IedmBatchChangeState. It produces the same error dialog and successfully changes state.

I still don't understand why I cannot use a standalone app to change state if there's a custom add-in.

I'm starting to think could this be caused by something I did wrong in the task add-in?

Edit: Is there any tech support for customer-built add-ins or standalone programs? I thought I remember seeing something in the customer portal, but it appears to be down for scheduled maint.

[AlexB]

Edit: Is there any tech support for customer-built add-ins or standalone programs? I thought I remember seeing something in the customer portal, but it appears to be down for scheduled maint.

image.png

Their email address is here if you need to contact them or call them. If you're on active subscription then you're eligible for assistance with API in addition to the rest of the software.

https://www.solidworks.com/sw/support/api-support.htm

[JSculley]

In case anyone cares, I was finally able to try the IedmBatchChangeState. It produces the same error dialog and successfully changes state.

I still don't understand why I cannot use a standalone app to change state if there's a custom add-in.

I'm starting to think could this be caused by something I did wrong in the task add-in?

Edit: Is there any tech support for customer-built add-ins or standalone programs? I thought I remember seeing something in the customer portal, but it appears to be down for scheduled maint.
image.png

I tried to replicate your problem in my development vault (SW2021 SP4). I used the task add-in sample from the API docs, and your minimal console program from your earlier reply (modified with my vault, file, state and transition names of course). With the task add-in installed I can run the console program, no dialogs are displayed and the file state is changed correctly.

Have you tried your console app with the task add-in removed from the vault? Have you tried installing the sample task add-in to see if it will also complain about failing to register when you run your console app?

FWIW my experiences with API support have been mostly bad. Slow to respond, slow to understand the problem, VB-centric, prone to forget about your problem unless you pester them, etc...

[bnemec]

I tried to replicate your problem in my development vault (SW2021 SP4). I used the task add-in sample from the API docs, and your minimal console program from your earlier reply (modified with my vault, file, state and transition names of course). With the task add-in installed I can run the console program, no dialogs are displayed and the file state is changed correctly.

Have you tried your console app with the task add-in removed from the vault? Have you tried installing the sample task add-in to see if it will also complain about failing to register when you run your console app?

FWIW my experiences with API support have been mostly bad. Slow to respond, slow to understand the problem, VB-centric, prone to forget about your problem unless you pester them, etc...

Jim, thank you for spending your time to try it on your side.

I'm reluctant to remove the task add-in from our vault. I was trying to put an email together to send to api support. With what you've reported back with I'm shifting focus away from the add-in and towards my existing task add-in. I'm going to set up test vault that I can do some state changing from standalone app but without my task add-in. Then add the add-in but don't create any tasks, then create a task that uses it, then... I think you get the idea.

[bnemec]

There's something wrong with my Task Add-in.

- Ran it against another vault that did not have our task add-in and no errors.
- Added the add-in in PDM Admin, did not create any task instances then ran the standalone change state app again and it failed to register the add-in.
- I created new project per the example Jim linked and installed that, removed my add-in, and ran the standalone change state app, no error.
- changed the Referenced from EdmLib to EPDM.Interop.epdm according to the other help pages, ran the standalone app, no error.
- added my task add-in back to the Add-ins node in Admin tool, ran the standalone app, failed to register error.

[bnemec]

While looking in Process Monitor when debugging and hit the ChangeState (also happens on unlock, undolock...) with both my task add-in and the example add-in installed. I see that both of them are loaded, well as long as my add-in was installed after the sample. I'm noticing that the sample add-in is loaded through:
C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\NetRegSrv.exe

and my add-in is attempted to be loaded using:
C:\Program Files\SOLIDWORKS Corp\SOLIDWORKS PDM\AddInRegSrv64.exe

I don't know what that means or if it is of any significance.


I'm trying to put together an email to api support that is concise and includes all the info they would need and leaves out the ramblings that they do not need. It's hard to provide good troubleshooting data when I don't know the problem, only have symptoms.

[JSculley]

There's something wrong with my Task Add-in.

- Ran it against another vault that did not have our task add-in and no errors.
- Added the add-in in PDM Admin, did not create any task instances then ran the standalone change state app again and it failed to register the add-in.
- I created new project per the example Jim linked and installed that, removed my add-in, and ran the standalone change state app, no error.
- changed the Referenced from EdmLib to EPDM.Interop.epdm according to the other help pages, ran the standalone app, no error.
- added my task add-in back to the Add-ins node in Admin tool, ran the standalone app, failed to register error.

A stab in the dark. Did you use the GUID tool to create the GUID for your task add-in? It has to be unique. It shouldn't be the same as any other GUID in the universe.

[bnemec]

A stab in the dark. Did you use the GUID tool to create the GUID for your task add-in? It has to be unique. It shouldn't be the same as any other GUID in the universe.

Thank you,

I was just going through all the AssemblyInfo.cs files for all the projects used in my task add-in to make sure that the ComVisible(false) not true. So we're shooting in similar directions in the dark.

I cannot recall 100% for certain that I did, but I don't know why I would not have; it was a long time ago. I use that tool regularly for other add-ins I have made. I follow some advice I've read (don't recall exactly where) to not expose the entire assembly from AssemblyInfo.cs (which has a GUID defined, I assume by VS when the project is created). Instead, I decorate the entry class to the addin with [Guid("307F1A58-1D40-45F2-9AE1-571DB43ACD58"), ComVisible(true)] So by default I use the GUID tool when doing that; I do not copy paste the GUID from the assemblyinfo.cs file to decorate my class definition.

I have not seen that GUID anywhere else in my filtering in Process Monitor or Process Explorer or in registry searches. Also, the add-in must be loading on all the clients and task host machine because it's working. Or is that a bad assumption?
I just used the GUID tool without thinking about it earlier today when I created the project for the sample add-in from SW help that you referenced.

To be honest I don't know what all would happen if I generated a new one and updated the add-in or I would just try it. I guess I could generate a new one, comment the old, build it then only update the file in my test vault then switch it back...

[bnemec]

I am such an idiot! So embarrassing. Looking in all the wrong places. Again.

When going through the text file in Solution 017133 line by line.

- If the Dispatch add-in loads ok, then there is most likely something with your compiled add-in that fails.
- When adding a .NET add-in, you must select both the compiled add-in dll and the “interop.edmlib.dll” file
- If the add-in is to be run on a 64-bit system, ensure it is compiled with correct options. check the following KB solution for details: S-017655.
- Ensure .NET add-ins are compiled with "COM Interop" option enabled.
- Try adding the add-in from another client instead.
- If you update an existing .NET add-in, it may be required for the client system to reboot twice before the new add-in dlls are fully reloaded. A workaround to avoid rebooting is to kill and restart explorer.exe via task manager.
- If the Windows user account control (UAC) is set to high, it is possible that some add-ins fail loading correctly. Try lowering the setting or starting Administration tool with 'Run as Administrator'.
- Also see KB solutions S-059092 and S-059088.

I checked the add-in project and all its dependency projects that they all have Platform Target set to x64. They did. I checked the KB for S-017655 but it's still off line.
Continuing down the list checking things. Then it hit me, that sinking feeling I get with the dawning awareness that I've potentially really screwed up. I go check the Platform Target of the quick standalone console app I made to test this "problem" and it's still set to "Any CPU" more sinking feeling. Prefer 32-bit is checked... I uncheck that one fr#$%@ng little checkbox and hit F5... Nothing, it silently flipped the state. Head to table moment. I switch the code back to our production vault and run again. Smooth sailing.

This isn't the first time I've lost days of my life to compiling for the wrong platform, yet I still get nailed by this...

I'm sorry for bothering you all.

On the bright side I learned a bit more about add-ins being loaded.

[AlexB]

...
I go check the Platform Target of the quick standalone console app I made to test this "problem" and it's still set to "Any CPU" more sinking feeling. Prefer 32-bit is checked... I uncheck that one fr#$%@ng little checkbox and hit F5... Nothing, it silently flipped the state. Head to table moment. I switch the code back to our production vault and run again. Smooth sailing.

This isn't the first time I've lost days of my life to compiling for the wrong platform, yet I still get nailed by this...

I'm sorry for bothering you all.

On the bright side I learned a bit more about add-ins being loaded.

I have always heard that this is something to check within a program when using the PDM or Solidworks API, but I don't know what issues it causes if you don't. Now I know.

Thanks for letting us know some symptoms and the resolution to your issue. I'm sure it will help others.

[JSculley]

I am such an idiot! So embarrassing. Looking in all the wrong places. Again.

...
...
...
Prefer 32-bit is checked... I uncheck that one fr#$%@ng little checkbox and hit F5... Nothing, it silently flipped the state. Head to table moment. I switch the code back to our production vault and run again. Smooth sailing.

This isn't the first time I've lost days of my life to compiling for the wrong platform, yet I still get nailed by this...

If you use add-ins you never have to worry about it. That checkbox is disabled.

[bnemec]

If you use add-ins you never have to worry about it. That checkbox is disabled.

Thanks but edit:kinda hard I don't know how to get other systems to run PDM tasks.

[bnemec]

I have always heard that this is something to check within a program when using the PDM or Solidworks API, but I don't know what issues it causes if you don't. Now I know.

Thanks for letting us know some symptoms and the resolution to your issue. I'm sure it will help others.

I don't understand all that goes on, but the 64bit dlls are registered/loaded differently than the 32bit. I don't know if or how some add-ins register both the 32 and 64 bit. I THINK that this was a problem only for my add-in because I had a 32bit standalone trying to register a dll that was 64bit only so it was going off the rails somewhere in that process. Perhaps if my task add-in was compiled for 32bit then my 32 bit stand alone would have been fine. Maybe someone that understands the underlying mechanisms can explain it better for us.
This is one of those "Applied programming concepts" as I call them that are important when working with add-in code but are not specific to any one software's API. I remember reading from Jason Newell about this in the past and I could barely grasp it.

This was a popular topic on the Solid Edge Dev Forum back when ST9 rolled out as it had the big switch to pretty much only 64bit dlls. Bit me three years ago:

https://community.sw.siemens.com/s/ques ... 9-and-2019
You'd think I would learn; but instead, I need a hard reminder every few years I guess.

I do hope this helps others, be nice if they see it before they waste time trouble shooting in the wrong direction like I did/do.

For future ref, if you're having dlls fail to register check this setting for your project properties. It should likely be 64bit only, or "Prefer 32-bit" NOT checked.

Maybe I should change my signature to mention this. May as well add something about [STAThread] too.