AnsweredAssumed Answered

Add-in error after updating to 2018 SP5.0

Question asked by Alex Burnett on Jan 29, 2019
Latest reply on Jan 30, 2019 by Alex Burnett

Like • Show 0 Likes0
Comment • 29

I wrote a custom c# add-in that uses the API and worked great when we were using SW2016 SP5.0. However, when we updated to 2018, I started encountering strange errors that are causing some calls to break.

I can't wrap my head around the reason for this error or a potential fix.

Scenario:

I have a drawing open. I click export on my add-in to output a STEP file. The add-in goes through the print to find the referenced document file path and then calls ActivateDoc3(Name, UseUserPreferences, Option, ref Errors). None of these variables are null or incorrectly formatted.

Error:

ActivateDoc3 Error

Could not load file or assembly 'gdtanalysissupport, Version=11.37.0.0, Culture=neutral, PublicKeyToken=[a bunch of numbers]' or one of its dependencies. The system cannot find the file specified.

The 3D referenced file does not open and causes further issues. I don't know why that DLL is being called nor do I know why it can't find it. It's located in my installation folder, right where it was installed. Has anybody encountered this or have any suggestions?

I know it's usually best to supply code and example files but neither of those are options and I can't recreated this with every file unfortunately. It only happens to some so I can't create a test file and repeat it.

Jim Sculley Jan 30, 2019 11:42 AM

Correct Answer

How are you creating your add-in project? Are you using the wizard for Visual Studio provided by SOLIDWORKS?

I've attached a copy of the add-in project I used for testing. You will probably have to remove and re-add the broken project references before it will build. Make sure you point to the references in your SOLIDWORKS 2018 folder. Also, update the project Debug settings to the proper location for your SLDWORKS.exe file as the startup application as well. Build it and see what happens.

See the reply in context

No one else had this question

Outcomes

29 Replies

1 2FirstPrevious

Attilio Colangelo Jan 29, 2019 11:19 AM
Mark Correct
Correct Answer
FWIW, a bit of commiserating, I experienced enough (unrelated) issues with SW 2018 SP5.0 that I uninstalled and reinstalled to SP4.0. However, I have learned to never do battle with software in general and always go back to a known state. Don't know if that helps at all but there it is.
Like • Show 1 Like1
Actions
Jake Bakerin Jan 29, 2019 11:21 AM
Mark Correct
Correct Answer
Check this out
Like • Show 2 Likes2
Actions
Frederick Law Jan 29, 2019 11:28 AM
Mark Correct
Correct Answer
Did you recompile the dll with 2018 reference?
Does ActivateDoc3 have a successor in 2018 API?
Like • Show 1 Like1
Actions
Deepak Gupta Jan 29, 2019 11:29 AM
Mark Correct
Correct Answer
Check if drawings showing issues are being opened as lightweight as that might be causing the issue. Also try using OpenDoc6 instead of ActivateDoc3
Like • Show 1 Like1
Actions
Alex Burnett Jan 29, 2019 11:40 AM
Mark Correct
Correct Answer
An even weirder issue. I duplicated the code for a problem file in a standalone console application. It works just fine. Something is going on in the add-in where it's not working right. I don't know what to do about it since catching the exception still causes SW to break.

This code works by itself, but not in an add-in:

I guess this is just another SolidQuirk.
Like • Show 0 Likes0
Actions
Alex Burnett @ Frederick Law on Jan 29, 2019 11:49 AM
Mark Correct
Correct Answer
I recompiled with both 2016 and 2018. There is not successor to ActivateDoc3 from what I can find.
Like • Show 0 Likes0
Actions
Jim Sculley Jan 29, 2019 11:51 AM
Mark Correct
Correct Answer
That particular file not being found was associated with a great deal of trouble a while back:

SolidWorks error: "Could not load SolidWorks DLL: GdtAnalysisSupport.dll."
SolidWorks Thumbnails Graphics Do Not Display
Re: KB3072630 Windows update causing add in issues

The problem was supposedly solved with SW2015 SP5 and SW2016 SP0 and onward so it may not be relevant here.

Does the error happen consistently for a given file? Or does the same file succeed sometimes and fail at other times? Is it happening to multiple users on multiple machines?

If you copy the relevant code in to a macro, does it fail in the same manner?
Like • Show 1 Like1
Actions
Alex Burnett @ Jim Sculley on Jan 29, 2019 11:57 AM
Mark Correct
Correct Answer
Hi Jim,

- This happens consistently with the same file, regardless of user. It's not all files though.
- I copied the exact code to another standalone API application and it succeeded just fine.

I don't know where to even start troubleshooting why this is happening but I'll try OpenDoc6 to see if that solves anything.
Like • Show 0 Likes0
Actions
Jim Sculley @ Alex Burnett on Jan 29, 2019 1:15 PM
Mark Correct
Correct Answer
Does the process fail if you do it manually? For example, open the drawing, activate the model, and then export to STEP using the normal SOLIDWORKS menu commands?

Since you have working code in a console application, what happens if you copy that code into a new add-in? If it no longer fails, there is probably some sort of registry problem with your original add-in.
Like • Show 0 Likes0
Actions
Alex Burnett @ Jim Sculley on Jan 29, 2019 2:45 PM
Mark Correct
Correct Answer
The code copied directly to the add-in still fails for some reason. Performing the task manually works just fine. My add-in isn't an installable application, it's simply a DLL that's registered to SW as an add in so the only registry entry should be the GUID. I can still take a look at uninstalling and reinstalling it from there.
Like • Show 1 Like1
Actions
Artem Taturevych @ Alex Burnett on Jan 29, 2019 2:49 PM
Mark Correct
Correct Answer
Make sure that Embed Interop option for sw interops is set to False in your project.
Like • Show 1 Like1
Actions
Jim Sculley @ Alex Burnett on Jan 29, 2019 2:56 PM
Mark Correct
Correct Answer
I have seen all sorts of bad behavior caused by multiple versions of DLLs being registered. Use regedit.exe to search for your GUID and see if you have multiple versions listed under InprocServer32:

Delete any versions that don't match what you see when you look at the details tab for your DLL:
Like • Show 1 Like1
Actions
Alex Burnett @ Artem Taturevych on Jan 29, 2019 3:16 PM
Mark Correct
Correct Answer
They are false already. I made sure to do that since multiple sources indicated it could cause weird behavior if I didn't.
Like • Show 0 Likes0
Actions
Alex Burnett @ Jim Sculley on Jan 29, 2019 3:17 PM
Mark Correct
Correct Answer
It shows version 1.0.0.0 as it should.
Like • Show 0 Likes0
Actions
Jim Sculley @ Alex Burnett on Jan 29, 2019 4:12 PM
Mark Correct
Correct Answer
Alex Burnett wrote:

An even weirder issue. I duplicated the code for a problem file in a standalone console application. It works just fine. Something is going on in the add-in where it's not working right. I don't know what to do about it since catching the exception still causes SW to break.

This code works by itself, but not in an add-in:

I guess this is just another SolidQuirk.
Just to be clear, you aren't calling Activator.CreateInstance from inside your add-in are you? That was just part of your console application, right? And the code above from 'int errors' to 'Console.ReadKey()' will fail when you put it in an add-in with nothing else but the code to execute it?

Can you post your problematic file? If you copy the file, does the copy misbehave as well? If you delete the geometry from the file does it misbehave?
Like • Show 1 Like1
Actions
Artem Taturevych Jan 29, 2019 5:03 PM
Mark Correct
Correct Answer
Try ActivateDoc2, I remember having problem with ActivateDoc3
Like • Show 0 Likes0
Actions
Alex Burnett @ Artem Taturevych on Jan 29, 2019 5:18 PM
Mark Correct
Correct Answer
Unfortunately, that returns the same error. Same with ActivateDoc.

OpenDoc6 doesn't work on a file that's technically already open in memory for a drawing. All I'm trying to do is bring it up as the active document so that I can save it as a 3D file type properly.
Like • Show 0 Likes0
Actions
Alex Burnett @ Jim Sculley on Jan 29, 2019 5:21 PM
Mark Correct
Correct Answer
You're correct, I made that code in the console app only. The add-in code is very differently. I copied the values directly from my add-in to run in that and everything worked correctly.

Unfortunately, I can't post the problem files since they're proprietary and I can't re-create the issue from scratch. I'll check the copy thing when I'm back in the office tomorrow.
Like • Show 0 Likes0
Actions
Artem Taturevych @ Alex Burnett on Jan 29, 2019 5:34 PM
Mark Correct
Correct Answer
One more question, are you using Activator.CreateInstance to connect to SOLIDWORKS (like in your example for stand-alone) in your add-in or you are using the pointer passed from ConnectToSw method?
Like • Show 0 Likes0
Actions
Alex Burnett @ Artem Taturevych on Jan 29, 2019 9:12 PM
Mark Correct
Correct Answer
I'm using the pointer from the Connect to SW method.
Like • Show 0 Likes0
Actions
Deepak Gupta @ Alex Burnett on Jan 30, 2019 1:14 AM
Mark Correct
Correct Answer
Alex Burnett wrote:

OpenDoc6 doesn't work on a file that's technically already open in memory for a drawing.
It always work for me.
Like • Show 0 Likes0
Actions
Alex Burnett @ Deepak Gupta on Jan 30, 2019 9:12 AM
Mark Correct
Correct Answer
I'll try it again and let you know how it goes then. Maybe I just did something wrong with the arguments.

OpenDoc6 returned with 0 Errors and a code 130 on warnings. I am assuming this is a combination of 128 and 2 from the api help documents where
128 = file is already open
2 = file is read only

Although it completes without issue, the document doesn't actually open at all. This problem is getting weirder and weirder which is leading me to think it's a crusty old template file problem or something. I have already pushed to have our current templates updated, but that hasn't happened yet and it won't improve our legacy files that have been around since 2006 or earlier.
Like • Show 0 Likes0
Actions
Alex Burnett Jan 30, 2019 9:35 AM
Mark Correct
Correct Answer
I went through the process of removing all of the features and other proprietary items from the files. I don't know if any of you could take a look at them to see what you can find out.

Like I said before, my add in is having a problem with the drawing file open and calling ActivateDoc3 to bring the referenced file up as the active document. It works fine when written into a macro or a standalone API application that connects to the active instance of SW. I feel it's an issue specifically with an add-in style program itself.
Attachments
- 83624.sldprt.zip53.3 KB
- 83623 - 2018.SLDDRW.zip48.4 KB
Like • Show 0 Likes0
Actions

Jim Sculley @ Alex Burnett on Jan 30, 2019 10:24 AM

I created a new add-in with this code in it:

  DrawingDoc dDoc = iSwApp.ActiveDoc as DrawingDoc;
            View v = dDoc.GetFirstView() as View; //This is the sheet
            v = v.GetNextView() as View; //First model view
            ModelDoc2 mDoc = v.ReferencedDocument;
            int errors = 0;
            iSwApp.ActivateDoc3(mDoc.GetTitle(), false, (int)swRebuildOnActivation_e.swDontRebuildActiveDoc, ref errors);

I opened a drawing, clicked the button to run the add-in code and the model was activated as expected. This was using SW2018 SP2. I'm installing SP5 on my test machine and will try it on that in a few minutes.

Actions

Jim Sculley @ Alex Burnett on Jan 30, 2019 11:01 AM
Mark Correct
Correct Answer
Same results with SW 2018 SP5. Part document is activated successfully.
Like • Show 0 Likes0
Actions

Add-in error after updating to 2018 SP5.0

Outcomes

Attachments

Related Content

Recommended Content