New project refers to older versions of VS Code and VS Pro

rbin_robotik
Contributor

New project refers to older versions of VS Code and VS Pro

rbin_robotik
Contributor
Contributor

Hello,

 

I'd like to report a minor annoyance for the add-in developers, especially when the add-ins are becoming bigger and more complex. I also would like to emphasize on "minor" here; the following are not critical issues, but it would be great if they could be fixed. At least, it would get rid of the annoyances.

 

When I create a Python add-in via Utilities -> Add-Ins -> Scripts and AddIns menu, it generates the template perfectly, and it also creates the ".vscode/settings.json" file. Inside this file, there is a variable called "python.pythonPath". It looks like VSCode replaced this variable with "python.defaultInterpreterPath" some time ago. However, Fusion 360 add-in template generator still uses the deprecated variable.

 

Similarly, when I create a C++ add-in, the template is generated perfectly, but the "{addin_name}.vcproj" file has references to VS Platform Toolset v110, which corresponds to Visual Studio 2012. Also the platform architecture is set to "x64". I downloaded VS Express 2012 from Microsoft Dev Essentials program (unfortunately, that is the only free version I could get for testing purposes after some googling) and installed it. It doesn't include "x64" compilers and linkers. "Win32" mode won't link against "core.lib".

 

After some research, I saw other developers take "SpurGear" as a starting point for C++ development. I checked SpurGear's ".vcproj" file and the platform toolset is set to v140, which corresponds to Visual Studio 2015. The good thing is that it is possible to install "MSVC C++ Build Tools v140" package from Visual Studio Installer for any supported version of Visual Studio. Therefore, x64 builds and linking work fine on this toolset.

 

I was wondering if there would be a chance to update variables discussed above to eliminate some annoyances. I am not asking to upgrade everything to the latest VS 2022. I am sure when the time comes, you will make the necessary changes. It would be just enough to change "v110" to "v140" would be a great help. As you all know, software development can get complicated from time to time and making the starting point less complex might be super helpful (and make prospective devs less prone to giving up).

0 Likes
Reply
300 Views
2 Replies
Replies (2)

BrianEkins
Mentor
Mentor

I asked about this a while ago, and the answer was that the projects could be easily upgraded to a newer version, but it's more difficult to go backward. However, I agree with you that it's probably time to update them to something newer than they currently use.

---------------------------------------------------------------
Brian Ekins
Inventor and Fusion 360 API Expert
Website/Blog: https://EkinsSolutions.com
1 Like

rbin_robotik
Contributor
Contributor
I see the point here, and I completely agree on the issues of going backward. On the other hand, Visual Studio 2015 is a very old toolkit, maybe there is no need to go that backward. My suggestion was v140 and if I remember correctly, that version of VS would be compatible with a decent amount of older and newer Visual Studios and all v14x series should be binary compatible, too.

It looks like VSCode also stopped calling "python.pythonPath" a deprecated variable, it just says unknown variable on the latest version 🙂 This is not a big deal, for sure.

I had another question: How should we proceed on this? Is this forum post enough or should I do something else to get the attention of the devs?
0 Likes