When to migrate add-ins to .NET 5?

SOLIDWORKS API/VBA Macros
1

I develop a bunch of add-ins, as my own products and custom add-ins for my clients. I have also forked SolidDna, although I hope my changes will be merged back some day. All add-ins now target .NET Framework 4.7.2 or 4.8.

I would like to keep up with the times, so I prefer to migrate to .NET Core or .NET 5. But when and how? There is no official source on the combination of .NET and SolidWorks, so I’m asking it here.

I know .NET Framework 4.8 is here to stay, but should we still want to upgrade?

2

Microsoft seems to be heading in a direction of phasing out this COM stuff (I could be wrong). I noticed that compile process for COM interop in .NET core and Std got more complicated from .NET framework and they probably half-assed it for legacy reasons.

I think we may need to wait for guidance from SOLIDWORKS Corp.

@artem might have a different opinion.

3

Yeah, SolidWorks is not so fond of guiding us…

COM seems to be at least supported now, since .NET Core 3.0 it seems:

But I still have no idea where to start.

4

You can watch this video which I have published some time ago which explains how to register .NET Standard and .NET Core for COM (this will be the same for .NET 5/6 as it is effectively new generation of .NET Core 3). It is not that hard - just different.

I have been preparing for the switch to .NET Standard/Core/5 for SW API Development. xCAD.NET which I am using for all my projects is multiplatform targeting .NET Standard/.NET Core and .NET Framework. So once SOLIDWORKS supports .NET Core/5 I will just change a platform in the settings and will not need to do any other changes.

But for now, I am finding a few problems with .NET Core when run as in-process add-in. In particular some of the versions of dll conflict with other dlls. I believe the main reason for this is .NET Core does not treat strong-named assemblies as .NET Framework does so loading 2 versions of dlls alongside each other is not possible in .NET Core (I haven’t checked if it is still the case in .NET 5). Saying that it is still possible to create SOLIDWORKS add-in with .NET Core as shown in this video where I use Visual Studio Code to create, debug and run SW add-in (the same can be done in Visual Studio). But as I have mentioned before I have found several conflicts and I do not recommend building add-ins with .NET Core at this stage (I still use .NET Framework for add-ins).

However I have not found any limitations with .NET Core and out-of-process (stand-alone) applications. Here is the video demonstrating how to create stand-alone application in .NET Core (In Visual Studio Code).

5

Thanks for the detailed explanation, Artem. Glad to hear that I’m not behind while building add-ins in .NET Framework :wink:

I read somewhere that strong-naming no longer exists in .NET Core, but I hope something better will fill that void.

I had already found some of your .NET Core work and I’ll go through all these links again soon.