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.
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.
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…
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.
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:
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.
<()>
