Setting Up and Troubleshooting Your SolidWorks Add-in Development Environment. Take off, eh…
Posted by Jeff Cope at 12 June, 2008, 1:31 am 
Writing Add-ins in SolidWorks can be tricky stuff as it involves class libraries, COM, interfaces, etc… It can be argued whether it is easier or harder in .NET (ease of use of .NET versus pain in the rear of COM Interop) but your good friends at SolidWorks set out to make it easy on all of us by creating Visual Studio templates for quickly creating SolidWorks Add-ins. The templates are packaged with the SolidWorks API SDK, support VB and C# and are analagous to having a SolidWorks part template that already has some geometry in it, custom properties, material assigned, etc… When it was introduced back in the day, it was a Godsend. It does have its issues from time to time though. For some reason, I have had trouble deploying both on SolidWorks 2007 and 2008. The SolidWorks API SDK installer runs without errors but when I attempt to create a new SolidWorks Add-in, I see this unfriendly message:
The I have spoken to a few other developers and concluded that I am not the only one so I decided to write a post on it. Besides, I go through this everytime I have to reinstall SolidWorks, which is just often enough to be a real pain but not quite often enough for me to ever remember the steps to fix the issue. I should admit then I am writing this as much for myself as I am for you. Here goes…
The Cause:
Based on the error message, you might get the impression that this is a trust or security issue. That might lead you down a path of signing the dll with a strong name, configuring .NET security policy on your machine, etc… (i.e. the path to frustration). To find the real cause, we must examine the Global Assembly Cache, GAC, to take a look at this SolidWorksTools dll file. The GAC is where shared .NET assemblies are placed so that they can be made available to other applications. On Windows XP, the GAC is located at “C:Windows\assemblies\”. Taking a look at the GAC, we see that it contains a different version of the SolidWorksTools dll file than that which is expected by the SolidWorks Add-in Template for Visual Studio. The version in the GAC is version 2.0.0.0 and not version 1.0.0.1, which is what the SolidWorks Add-in Template for Visual Studio is looking for.
If we take a look at the template itself, then we can see where the version is specified for the SolidWorks Add-in Template for Visual Studio. FYI, the template is contained in a zip file (SWVBAddin.zip for Visual Basic) which in turn is contained in the “…Templates\Project Templates\<Visual Basic or Visual C#>” folder of your Visual Studio 2005 directory. Note: I have Visual Studio 2008 but it is still in the box so I’ll let you know once I try it if the templates go in the same place.
The zip file contains various bitmaps, icons, classes and modules as you would expect to see in an Add-in but it also a file called VBAddin.vstemplate which is a Visual Studio template file. Once you open it, you see that indeed a different version of the SolidWorksTools dll file has been specified than the one which is installed in the GAC. .
In theory, one should be able to update the VBAddin.vstemplate file above to refer to the insalled version of the SolidWorkTools dll file. One of my favorite philosophers once explained why this might not work for me:
”In theory there is no difference between theory and practice. In practice there is.” - Yogi Berra
What I do is just to uninstall the SolidWorksTools dll file in the GAC (right mouse button on the file in the GAC and select uninstall) and replace it with the version 1.0.0.1 file that SolidWorks API support gave me the first time I ever reported this issue (a long time ago, in a galaxy far, far away…) . You can do this by simply dropping the file in the GAC folder (e.g. C:\Windows\assemblies).
Once you add the version 1.0.0.1 SolidWorksTools dll file to the GAC, you can go into Visual Studio and attempt to create a new SolidWorks project from the SolidWorks Add-in Template for Visual Studio.
And it works! Now you can begin writing that Add-in (i.e. the one that is now a few days late while you fought with the SolidWorks SDK).
Note: For any SolidWorks Add-ins that were previously compiling using the 1.0.0.1 dll, you will have to change your Visual Studio Project to reference the newer version.
Good luck.
If you enjoyed this post, make sure you subscribe to my RSS feed!
- Bookmark :
- Digg
- del.icio.us
- Stumbleupon
- Redit it
Jeff,
Your site is great! I am the primary SolidWorks API guru at Fisher/Unitech (VAR). I have been been programming w/SolidWorks for several years now and I appreciate the value of great resources like your site and I’m always looking to network w/people who work w/the API.
Keep up the good work!
Brendan
Thanks Brendan for the post. It is good to know someone is reading my articles. It would really suck if I was doing it for nothing. When nobody comments, I wonder if I helped anyone. Thanks again and I’ll be in touch the next time I run into a problem and want to run it by fellow SolidWorks API technoweenie.
Jeff
cool man, I’ve always wondered how to do this stuff. I still don’t understand it completely but you’re giving me more insight to how it works and it doesn’t seem so overwhelming.
I’m a novice for sure, but wonder how to even handle SolidWorks version changes and an add-in step by step. good stuff man!
Hey guys…I just “upgraded” to Windows Vista Ultimate on my development machine and I ran into a couple of new issue that I haven’t seen before.
Issue 1: The SolidWorks API SDK Installer ran without errors but didn’t install the addin template zip files to the …\Visual Studio 2008\Templates\Project Templates\\ directories. I happened to have them “lying around” so I added them there myself.
Issue 2: The SDK Installer added the SolidWorksToolsWizard.dll to the Global Assembly Cache but it did not add the SolidWorksTools.dll so even after fixing issue #2, I still got no love. I attempted to add it manually but I ran headlong into Issue #3.
Issue 3: When attempting to manually add the SolidWorksTools.dll to the GAC myself via the “gacutil /i solidworkstools.dll” command, I was informed by Windows that…”Failure adding assembly to the cache: Access denied. You might not have sufficient priviliges…blah…blah…blah…” I was quite surprised at this since I am an Administrator and only user on this machine. After looking through some Google hits, (I love you Google-you are always my shoulder to cry on when Microsoft makes me sad) I followed a poster’s recommendation and turned off “User Account Control” from the control panel. This required a reboot but once I did it, I was able to add SolidWorksTools.dll to the GAC and then I was able to create a new VB 2008 SolidWorks Add-in. Hooray!
I’ve downloaded the files from solidworks.com and to my surprise: it worked as described!
I didn’t had to change any files!
One problem I had: I copied the .dll file per TotalCommander to the directory, instead of using explorer *yuck* drag&drop!
I am new to solidworks api using c++ and vb. I could write macros using vba and i want to use c++ api, any help/tutorial or guidelines is highly appreciated. Thanks in advance
What I do is just to uninstall the SolidWorksTools dll file in the GAC (right mouse button on the file in the GAC and select uninstall) and replace it with the version 1.0.0.1 file that SolidWorks API support gave me the first time I ever reported this issue (a long time ago, in a galaxy far, far away…) . You can do this by simply dropping the file in the GAC folder (e.g. C:\Windows\assemblies).
From the above if it does not allaw you to uninstall this “cannot uninstall it is required by other program” what do you do.
Where do you get this new 2.0.0.0.1 dll file