The #ifdef is referencing a Windows-specific header file when you're compiling with Visual Studio. A big difference between using C++ and Python is that most Python code will run as-is on either Windows or Mac. Typically, you can develop your add-in on one and it will automatically work on the other. The times it won't is when you're making an OS-specific call, like accessing the Windows registry.
With C++ you can typically get by with one set of source code but you have to compile it specifically for Windows or Mac. Unlike with Python, there are always some differences in the source code, which explains why the #ifdef is there. Compiling under Windows with Visual Studio will create a dll. Compiling on Mac with XCode will create a dylib. If you want to support both platforms you need to install the dll on Windows and the dylib on Mac.
Each add-in has its own folder, which is the same name as the dll and dylib file. In that folder is the dll or dylib and also the .manifest file with the same name. There are some standard folders where Fusion looks for add-ins. Within those folders, it looks for subfolders and within those, it looks for manifest files. If the manifest file indicates the add-in should be loaded at start-up, Fusion will load the dll or dylib file and the add-in will start running. You can manage your add-ins through the "Scripts and Add-Ins" command where you can see a list of scripts and add-ins that Fusion has found. For each add-in, you can specify if it should run automatically at start-up or not.
I don't know what the problem with debugging is. I just tried it myself and was able to start successfully debugging a script using the directions from here: https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-ECC0A398-4D89-4776-A054-F7B432F7FCF6#Debuggi...
---------------------------------------------------------------
Brian EkinsInventor and Fusion 360 API Expert
Website/Blog:
https://EkinsSolutions.com