We are thinking about switching our software development from .net framework to a newer .net version (core or 5.0 or 6.0) since framework is not going to be developed further (so it's going to be dead at some point).
Since we write quite a lot Swx addins and standalone projects (where Swx is remotely started and controlled), we must be sure that the Swx API works as expected. But it seems that the Swx API dlls are still not available for .net core, .net5 or .net6, only .net framework.
I know that there is an open-source library that allows writing Swx addins in .netcore3.1 (see https://xcad.xarial.com/), but it still uses the (only available) Swx API dlls targeted for .net framework. Has anyone used this with .netcore3.1 and can confidently say that it works well?
And what about .net5 and .net6?
It seems the xcad library does not yet support .net5 or .net6, but I checked the content of the xcad nugets and modified the targets file (in build folder) of xarial.xcad.solidworks.0.7.12.nupkg so that the registering command also includes net5 and net6. Then, as far as I can see, it works for .net5 as well (I used net5.0-windows as target framework); I was able to write a test addin just like here: https://forum.solidworks.com/thread/242319 that shows a message box at Swx startup. But it did not work for .net6 because the [ComRegisterFunction] and [ComUnregisterFunction] attributes don't seem to work; i.e. the functions marked with these attributes are not called.
Maybe @artem, the creator of xarial.xcad, could help?
Swx API for .netcore3.1 or .net5 or .net6
Swx API for .netcore3.1 or .net5 or .net6
Hi,
I would recommend not to switch to .NET Core/NET5/6 just yet if you are developing add-ins until SOLIDWORKS officially supports this. It is OK to use .NET Core/NET5/6 in stand-alone applications though.
One of the main limitations of .NET Core/.NET5 is an inability to load two different versions of dlls alongside each other (it is possible in .NET Framework when assemblies are strong-named, but the strong name is redundant in .NET Core/.NET5). This brings lots of compatibility issues. Even in this example: https://github.com/xarial/xcad-examples ... bEfNetCore, if you upgrade to the latest version of Entity Framework Core it will stop working without any obvious reasons.
In some cases, it is the main requirement to use .NET Core (for example there is an existing codebase in .NET Core), so it might be worth using .NET Core (especially if this is for internal use projects), but if there is no strong need for that, I would keep it in .NET Framework. I still use 4.6.1 for all my SW add-ins.
Go to full postI would recommend not to switch to .NET Core/NET5/6 just yet if you are developing add-ins until SOLIDWORKS officially supports this. It is OK to use .NET Core/NET5/6 in stand-alone applications though.
One of the main limitations of .NET Core/.NET5 is an inability to load two different versions of dlls alongside each other (it is possible in .NET Framework when assemblies are strong-named, but the strong name is redundant in .NET Core/.NET5). This brings lots of compatibility issues. Even in this example: https://github.com/xarial/xcad-examples ... bEfNetCore, if you upgrade to the latest version of Entity Framework Core it will stop working without any obvious reasons.
In some cases, it is the main requirement to use .NET Core (for example there is an existing codebase in .NET Core), so it might be worth using .NET Core (especially if this is for internal use projects), but if there is no strong need for that, I would keep it in .NET Framework. I still use 4.6.1 for all my SW add-ins.
Re: Swx API for .netcore3.1 or .net5 or .net6
Hi,
I would recommend not to switch to .NET Core/NET5/6 just yet if you are developing add-ins until SOLIDWORKS officially supports this. It is OK to use .NET Core/NET5/6 in stand-alone applications though.
One of the main limitations of .NET Core/.NET5 is an inability to load two different versions of dlls alongside each other (it is possible in .NET Framework when assemblies are strong-named, but the strong name is redundant in .NET Core/.NET5). This brings lots of compatibility issues. Even in this example: https://github.com/xarial/xcad-examples ... bEfNetCore, if you upgrade to the latest version of Entity Framework Core it will stop working without any obvious reasons.
In some cases, it is the main requirement to use .NET Core (for example there is an existing codebase in .NET Core), so it might be worth using .NET Core (especially if this is for internal use projects), but if there is no strong need for that, I would keep it in .NET Framework. I still use 4.6.1 for all my SW add-ins.
I would recommend not to switch to .NET Core/NET5/6 just yet if you are developing add-ins until SOLIDWORKS officially supports this. It is OK to use .NET Core/NET5/6 in stand-alone applications though.
One of the main limitations of .NET Core/.NET5 is an inability to load two different versions of dlls alongside each other (it is possible in .NET Framework when assemblies are strong-named, but the strong name is redundant in .NET Core/.NET5). This brings lots of compatibility issues. Even in this example: https://github.com/xarial/xcad-examples ... bEfNetCore, if you upgrade to the latest version of Entity Framework Core it will stop working without any obvious reasons.
In some cases, it is the main requirement to use .NET Core (for example there is an existing codebase in .NET Core), so it might be worth using .NET Core (especially if this is for internal use projects), but if there is no strong need for that, I would keep it in .NET Framework. I still use 4.6.1 for all my SW add-ins.
Thanks,
Artem
xarial.com - making your CAD better
codestack.net - SOLIDWORKS API macros and tutorials
Artem
xarial.com - making your CAD better
codestack.net - SOLIDWORKS API macros and tutorials
Re: Swx API for .netcore3.1 or .net5 or .net6
Regarding .net6:
If COM registration does not work, try adding the following property to the project file (i.e. into some <PropertyGroup>):
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Microsoft docs say about it:
If COM registration does not work, try adding the following property to the project file (i.e. into some <PropertyGroup>):
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Microsoft docs say about it:
Credit goes to Artem Taturevych for finding that out.The CopyLocalLockFileAssemblies property is useful for plugin projects that have dependencies on other libraries. If you set this property to true, any NuGet package dependencies are copied to the output directory. That means you can use the output of dotnet build to run your plugin on any machine.