If you’re interested in automating some or all of your company’s workflow on your own or with the help of CADSharp’s automation services, you need to answer this very important question: Is this problem best solved using a macro, add-in, or stand-alone? Answering this question requires us to answer several other questions:
- What are the technical differences between these three types of programs?
- How much time and money can I invest into this program?
- What is the skill level (in terms of programming and API) of the person writing this program? What languages does this person know?
- How do I want this program to be deployed? Maintained? Modified (if necessary)? Secured?
- How integrated with SolidWorks do I want this program to be?
In this article, I want to evaluate macros, add-ins, and stand-alones from a variety of perspectives so that you can make the best choice for your automation project. For those with limited time, skip to the Summary and Recommendations section at the end and you’ll probably find all of the information you need.
Macros
A macro is a program that runs only inside of another program. In the case of SolidWorks, macros come in two flavors: VBA macros and .NET macros. Both VBA and .NET macros can be recorded, run, and edited using the commands in Tools–>Macro.
VBA Macros
VBA macros are written using the Visual Basic for Applications (VBA) programming language in the built-in Visual Basic editor. Whether being edited or run, the .swp file is always used.
Advantages
- VBA is easier to learn than .NET languages (both VB.NET and C# are .NET languages), therefore VBA macros tend to be easier and faster to write (with some exceptions – see Disadvantages).
- VBA code can be modified even while the programming is running, making debugging much faster.
- VBA macros are contained in a single file, making them easier to store and share.
- More code samples exist in VBA than all other languages combined, which is another huge benefit to novice SolidWorks API programmers.
Disadvantages
- VBA lacks object-oriented programming capabilities (unlike .NET languages), making VBA macros more cumbersome for very complex programs.
- Due to idiosyncracies with 64 bit systems, VBA macros that use user forms or reference Windows DLLs can cause a lot of compatibility headaches that require extra code to resolve.
- Missing reference issues can occur when sharing VBA macros.
- Not a good choice if you always need your program running as long as SolidWorks is running (choose add-in instead), though it is possible.
.NET Macros
.NET macros are written using VB.NET or C# in the built-in Visual Studio Tools for Applications (VSTA) editor. When being edited, use the .vbproj or .csproj file found in the solution folder. When running from outside VSTA, use a compiled DLL. In my experience, however, these DLLs are unstable and for that reason I do not recommend using .NET macros as a serious part of your company’s workflow. If you really want to automate using the .NET language , create an add-in or stand-alone.
Note that I said “as a serious part of your company’s workflow”. This means a program that you might be deploying across the company or might expect someone else to maintain long after you are gone. That is very dangerous, in my opinion. On the other hand, if you simply want a macro for your own personal use, you should be fine. Also, if you’re new to .NET languages and need a sandbox in which you can play around or hone your skills, .NET macros are a great option since you don’t have to jump through all of the hoops of setting up an add-in or stand-alone.
Examples
If you’d like to see some VBA macro examples, we have hundreds available in our Macro Library.
Where to Start
If you want to start writing VBA macros, you can learn to run, edit, and create a simple VBA macro in the next couple of hours by watching our free online tutorials. No programming or API experience required.
Add-ins
An add-in, also known as add-on or plug-in, is also a program that runs inside of another program. Unlike macros, however, they must be registered and loaded before they can work properly. Add-ins can be written in VB.NET, C#, or C++, which means that they’ll be written and edited using Visual Studio project files and then run from a compiled DLL.
Advantages
- Preferable over VBA macros if you want a more integrated, SolidWorks-native look and feel to your program. Can be turned on and off using Tools–>Add-ins.
- The best choice for programs that always need to be running as long as SolidWorks is running (as long as the Startup checkbox is checked under Tools–>Add-ins).
- Written using VB.NET, C#, or C++, which are much more powerful, feature-rich languages compared to VBA (although more difficult to learn if you’re a beginner).
- More secure, since users probably don’t know how to reverse engineer the DLLs. This means the code is kept private and safe from tampering.
Disadvantages
- The most complicated of the three types of programs to write. Not a good choice for new API programmers.
- Since add-ins run “in-process”, SolidWorks must be open for an add-in to run, unlike stand-alones.
- More administration overhead, since add-ins must be registered. This can be simplified somewhat if the add-in is distributed with an installer, but creating an installer also adds programming overhead.
Examples
If you’re using PhotoView 360 or any CAM package, you’re probably already familiar with using add-ins. Any add-in that is registered with SolidWorks will appear in Tools–>Add-ins.
Where To Start
If you’d like to start programming SolidWorks add-ins: First, I’d encourage you to get basic SolidWorks API programming using VBA under your belt. You’ll learn the API a lot quicker than if you try to start with add-ins. Second, I’d encourage you to watch some professional .NET training tutorials to learn VB.NET or C# (I recommend these and these). Unless you have a background in C languages, I’d recommend learning VB.NET over C#. Third, you can start practicing with add-ins using the SolidWorks SDK add-in templates.
Stand-Alones
A stand-alone is a Windows application that runs in its own process, outside of the SLDWORKS.EXE process, hence its name. Add-ins can be written in VB.NET, C#, or C++, which means that they’ll be written and edited using Visual Studio project files and then run from a compiled EXE or DLL, depending on the project type.
Advantages
- Tremendous flexibility. Stand-alone code can be part of a larger program that doesn’t only involve SolidWorks or they it can run or attach to multiple sessions of SolidWorks for the program’s duration.
- Easier to set up than add-ins.
Disadvantages
- Since stand-alones run outside of the SLDWORKS.EXE process, there is a slight performance decrease compared to add-ins and macros. This is insignificant in the majority of applications, however.
- Not ideal if your program needs to be integrated into the SolidWorks environment.
- Can’t use in-process methods. (Unless you’re writing unmanaged C++ code, this should never be a concern, however.)
Examples
If you have Visual Basic 2010 Express installed (recommended over 2012 Express) then you can download and look at a stand-alone I created in VB.NET that creates a part from parameters contained in an Excel spreadsheet. Both SolidWorks and Excel run invisibly while this occurs. If you need help running it, watch the last part of my SolidWorks World 2014 presentation titled “Using Microsoft Excel with the SolidWorks API”.
Where to Start
If you’d like to start programming SolidWorks stand-alones: First, I’d encourage you to get basic SolidWorks API programming using VBA under your belt. You’ll learn the API a lot quicker than if you try to start with stand-alones. Second, I’d encourage you to watch some professional .NET training tutorials to learn VB.NET or C# (I recommend these and these). Unless you have a background in C languages, I’d recommend learning VB.NET over C#. Third, you can learn how to set up a basic stand-alone in VB.NET, C#, or C++ using this tutorial by Artem Taturevich.
Summary and Recommendations
Macros run inside of SolidWorks are usually written with VBA. Since they’re easy to write and debug, they’re the ideal option for 1) new SolidWorks API programmers, 2) programmers with limited time, 3) programmers who have no need for some of the more robust capabilities of .NET programming languages, 4) personal use or use with no more than a few engineers within the same department.
Add-ins are like macros on steroids. They’re written with the more robust .NET programming languages (or C++) and allow for a more non-intrusive, integrated user experience since they can be turned on and off via Tools–>Add-ins. I would recommend add-ins for 1) experienced programmers who already know VB.NET, C#, or C++, 2) a strongly integrated program experience, 3) use across a company or several companies, 4) increased security needs (versus macros).
Stand-alones are also written using .NET or C++, but unlike add-ins they do not need to run inside the SolidWorks process, which gives the programmer extra flexibility. I would recommend stand-alones for 1) experienced programmers who already know VB.NET, C#, or C++, 2) programs that use SolidWorks in only one part of the program, 3) programs that need to work with multiple SolidWorks sessions during the duration of the program.
If you’re writing a program that you intend to sell or give to other companies and departments, you should definitely create an add-in or stand-alone.
Conclusion
I hope this article has shed light on the fundamental as well as subtle differences between macros, add-ins, and stand-alones. If you still have questions about which option is right for you, leave a comment or shoot me an email and we’ll discuss it.
Finally, don’t forget that CADSharp LLC has a great team ready to help you with your next automation project. Check out our Services page to learn more and request a quote.
Giving you the macro perspective,
Keith
Want to keep up with new CADSharp.com content? Sign up for our newsletter.
Great article Keith!