No matter which profile you chose, you can identify the shortcut for a command by opening the Options dialog box, expanding the Environment node, and then choosing Keyboard. This page lists the default command shortcuts for the General profile, which you might have chosen when you installed Visual Studio. I know SpurGear is just a sample, but it should reflect best practices.You can access a variety of commands and windows in Visual Studio by choosing the appropriate keyboard shortcut. More complicated projects may have additional build products, other files, dependencies and DLLs and it gets pretty sloppy having to copy these up where they are never 'cleaned'. This is a common practice and there are settings in the project to do just this. I did try copying the manifest and resources down to the appropriate debug directory where Fusion adds it just fine, but the breakpoint is still not reached.įWIW, to any Autodesk people listening: It's probably best to use the build process to copy the manifest and resources to the build directory than to copy the DLL up. That this ever works is interesting to me and suggests the debugger somehow identifies with the DLL even though its full path name is different. This obviously places it in the location with the manifest and resources, but it is NOT the same full file path name that the VS environment (and debugger) associates with the build product output which has the potential for great confusion. It concerns me that the sample build uses a Post-Build Event to copy the DLL from the Debug directory back up to the main folder.
This result should, I believe, alleviate any concerns about naming issues. I can then redo the scenario in VS 2017 where it still works.
And I've changed the "command has been added" msg to verify which version is running. I've even verified using Process Explorer that the DLL is in fact loading from the expected location. Loaded the same project in VS 2019 (ignoring suggestion to update platform and toolset - yes, I've tried it both ways), rebuild, launch Fusion, attach process, set breakpoint, AddIn already added at same folder location - verified by AddIn details, run AddIn (run on startup was not set), breakpoint NOT reached. Loaded the project in VS 2017, rebuild, launch Fusion, attach process, set breakpoint, add AddIn at this new folder location, run AddIn, breakpoint reached, shutdown Fusion. In reproducing this problem (yet again, N-th iteration) I have copied the SpurGear source (from "CPP\AddInSamples\SpurGear") to a local folder ("H:\SpurGear").
0 kommentar(er)
