To answer the question in the title of your post, the reason it won't register is that your project is targeting the .net framework 2 (or 3.5). SW2015 uses .Net 4.0
So, change your project settings to target .Net 4.0
C# is definitely preferable to C++ unless you are an expert programmer. VB.Net is an option. You can pretty much copy and paste your VBA code into a VB.Net project.
Thanks Simon for your reaction !
I'm going to find out where to change the project settings, can you point me in the right direction ?
If you have any tips for a tutorial, please let me know.
Between C# and VB.Net, what should you advise me ?
About registering in the registry, what is the right place ?
For SW 2015:
0. Run VS with admin privileges
1. Change the framework:
2. Click on Assembly Information and check Make Assembly COM-Visible
Now simply build you project, run sw and your add-in should appear in the add-in manager!
If you use the first registry path, the addin will be available to all SolidWorks versions installed on the local machine.
The second means it will only be available for SolidWorks 2015.
As Simon Turner said, C# is preferable over C++ for many reasons one of which is C# provides you with a built-in garbage collector that manages your memory for you. In C++, you manage memory by yourself to avoid memory leaks.
Thanks a lot Amen!
I'm gonna study when I'm back home.
Clear what about C# vs C++, what about C# vs VB.NET?
C# and VB.Net are virtually interchangeable. There are tools that will convert a C# project to VB.Net and vice versa.
So it's really down to what you are comfortable with.
If you have been using VBA up to now, then VB.Net might be the best choice.
There is nothing C# accomplishes that VB.Net can't (This goes against the common belief that C# is more "powerful" than VB.net). At the end of the day, all the C# and VB.net code is processed into intermediary language called the MSIL (Microsoft Intermediate language) which independent of the CPU before it gets complied into native code (machine readable binary which is CPU specific). So, not much of a major difference.
C# is "Cish" language like (C, C++, Java, objective C) so its syntax is close to C. It has advantages and shortcomings much like any other language in software development.
So when it comes to down to developing add-ins for SolidWorks, it's merely a preference of the person. Choose which ever you're comfortable using. Obviously, as Simon Turner, VB.net would be a good start if you're familiar with VBA (the little brother of VB.Net as I like to call it).
VB.net continues to be supported by Microsoft (Latest version is VB14) and you're good to go. Microsoft itself says there isn't a difference. I invite you to read this. Hopefully, it will help you make an informed choice.
Thanks all of you guys for your support and advises !
I've read the white paper regarding the differences between C# and VB.Net, clear story, looks like I'm better off with VB.Net for now, changed my plan.
Are you familiar with the bug(s) in VBA(swp) which triggers the fatal error and will crash SW ?
How about VB.Net regarding bugs and errors, is it more stable than VBA or what ?
Should I expect the same trouble with crashing macro's/code or ?
A part of my macro is to scan all the dimensions names from the sketches, when a right combination is found a custom property 'Size' is created.
For example, when the macro found a combination 'OD' and 'L' in the dimension names the custom property 'Size' is created and the value 'OD x L' is placed on the drawing corner/BOM so you have always the accurate size of a part or assembly on your corner/BOM, when the user didn't give specified names to the dimensions the macro is calculating the 'Box Size' from a part or assembly and place it on the corner/BOM.
How would you accomplice this in VB.Net ?
Simon stated, 'You can pretty much copy and paste your VBA code into a VB.Net project.', of course that's where I'm going to start however, any suggestion are more then welcome.
Also a project based file handling system is integrated into my macro, it recognizes the project number, increase part/assembly numbers, save drawings also as PDF and if needed as DWG etc.
For now some recent project data like recent project number etc. is placed in a text file by the macro and read the next time the macro runs.
Is there a better option for this technique when using VB.Net ?
Thanks again for reading, as said, any suggestion are welcome.
You should break down the bigger problem into smaller pieces. Think not of how you would accomplish all of those things in a single block of instructions but think about breaking this problem down into smaller seperate blocks of functionalities to make your code more agile.
Copy is pasting vba to VB.NET is "okay"ish but there are a few things that sets VB.NET from VBA apart. Take the example of variant types in vba that don't exist in VB.NET. So VBA is a good start but you need to revise the entire code once you take it to VB.NET...
its "visible" not visable
Your right Amen, thanks allot !