Odd DLL Behavior

[larry.daubenspeck]

We have a home-grown Inventor addin (2017) that is executed within an assembly.  It creates a new part (a cable) and then places it, along with some cable clamps.  If executed a second time (let's say something changed slightly in the cable routing), it first searches for any existing cables and clamps and deletes them before doing its thing.  All works well for a dozen designers.  The problem is that for 3 designers, while the subsequent execution deletes the clamps, it does NOT delete the cable (and this causes problems later in the program).  Same software, same DLL, same workflow, different results.  Actually, this problem has dogged us for years, through several software upgrades, as well as hardware changes.  

In the course of troubleshooting, one recent thing we tried was to export the Application Settings from a "working" PC, then import them into a "non-working" PC, but to no avail.  At the same time, we can't help but think it's some setting we've overlooked somewhere.

Are there any gurus out there with similar experiences, and hopefully, a timely suggestion?

Thanks in advance!

[bradeneuropeArthur]

Hi,

Same service pack of inventor?

Same Framework installed.

Are you having systems that have different settings like:

• Hide extensions for known file types. use the same settings for all.
• How did you deploy the add in, in the company?
• do you need server request for your code? use IP address instead of server-name or share.

Are you willing to share the code.

You could do that also with a private message

Regards,

[Brett.G]

How are you searching for the cable and clamp for deletion?  Are you searching through the occurrences in the assembly for a Part Number or some other property?  Could whatever field you're searching for somehow be different for those 3 users?

[larry.daubenspeck]

Thank you for your suggestions.  Yes, everything is the same, plus like I said, we've had the same issue through software and hardware upgrades.  The DLLs are stored on a server, and there is an executable which updates a users DLLs.  The DLLs are copied to a specific folder on each machine, so it's easy to check on the version being used.  The addin uses local files, so no access to servers is being utilized.

[larry.daubenspeck]

Brett, it's iterating through the occurrences, looking for a specific name.  The name is created the first time the addin is run.  The problem only appears on subsequent attempts.

[AlexFielder]

I would get the users whose machines misbehave to try and log into known-working machines to see if it's a (localised) user permissions issue when running the tool.

[Brett.G · Accepted solution]

One thing you may try is debugging the addin on one of the bad computers and following the code where the search for the Occurrence is taking place.   Perhaps there is something different happening with the search on the bad computers or the name is being created differently somehow.  

[bradeneuropeArthur]

Are you sure the correct dll are loaded. I test this with a visible version number in my add in name.
There are different locations to store the dll. Maybe they don't load the correct one because the old one is also in a different location. You understand my idea or suggestion,

[larry.daubenspeck · Accepted solution]

Thanks Brett.  We loaded MS VS onto a "problem" machine and traced the code to where it erred.  Sure enough, it was some obscure PC setting which was causing a False where there should've been a True.  The three "bad" PCs all had the Hide File Extensions checked.  This was causing a problem where the code was looking for the cable's file name.  Changing my code from using the Equals to Contains solved the problem.