How do I really learn MS Visual Studio

apologies for a bit of a rant…

I have committed to learning C / C++ this year. I feel I’m making good progress.
I built a functioning Maya API plugin, I have the start of my own 3D library.

It seems that Microsoft Visual studio is the single biggest friction point for me, and It gets quite frustrating.
I seem to spend more time fighting VS than learning to actually code.
It has so many obscure configuration settings and weirdly abstracted project structures.
Not at all like VS Code where your folders = your project structure.
It feels like a monolithic mess with barrier after barrier to learning.
Stuff I grab off git hub to learn from seems to never reliably build.
I am stuck with hours of crawling stack overflow to find the right fix for the specific error in my specific project and my specific VS version and the particular mess of local Windows SDK files and Build tools and other implicit dependencies I’m not even sure how to think about.

But surely it’s the industry standard for a reason?
Surely there is a sensible paradigm behind all the obfuscating structure and ad hoc terminology?

Is there any resource that can take a noob through the maze of Visual Studio’s thinking so I can get a grip on VS? Or am I left with banging my head against things and slowly accumulating painful wisdom?

I could (and have) use other IDEs, but I want to learn VS and not allow it to be the barrier it has been any more.

I know this isn’t what you’re asking, but I’m gonna go a different route and say you can probably go without deeply learning Visual Studio.

A big issue is the Windows-only nature of VS. There are many places that run Linux, so you have to set up a separate build system to compile for that. So why use two separate build systems, when you could use one that’s cross platform?
Also, did you know that you have to use different versions of VS to compile plugins for different versions of Maya? It doesn’t matter as much anymore, but having the build settings tied to a specific compiler toolchain is still a pain if you ever need to upgrade. So (again) why set up multiple build systems when you could use one that handles different compilers?

Right now, (IMO) the best choice is to use CMake.
CMake is a command line tool that builds build files. For instance on Windows, setting up and running CMake for a project will create a working .sln file (on Linux it builds the makefiles), and gives you a single consistent place to set all the settings. It also allows you to easily set up compiling for different versions of maya using the different required versions of VS.

It seems you can even integrate CMake into VSCode if you want. (I don’t use VSCode personally, so I’m only going off google search results)

My own workflow is basically: Set up a CMake script and .bat files from my templates. Write code in whatever text editor I like. Compile using CMake (which builds all the VS files you need in a way that just works). Then use the Visual Studio Debugger (which is probably the best part of VS, IMO).
Then once all that’s done, I just have to run my build script.
New maya version? Just update the maya version variable, and run the build script. No fuss.

I’d definitely suggest getting this:

And also watching his playlist on using cmake for building maya plugins:


Side note: I HATE CMake’s scripting language with a passion. But it works, and it’s used in most of the open source projects I’ve wanted to compile.

2 Likes

I had similar frustrations to Mambo, and I was also recommend CMake as an alternative to VS, but from what I could see, and sorry if I’m missing something: it doesn’t seem like it is?
CMake builds build files and solutions, but then (on windows) how do you actually compile those, other than using visual studio? It seems like the only default C compiler, the only one that windows maya understands. Is there an alternative?

CMake is just a unified front-end for managing compiler and linker settings. It is not a compiler or linker itself, it just gives you one way to define settings that it can translate between the different compilers. You still have to have those compilers installed to use them.

Visual Studio and the Microsoft VIsual C Compiler (MSVC) are tightly interconnected, but they are not quite the same thing. You could run the compiler (cl.exe) directly without ever needing to open VS. The project files (.sln) that VS creates and maintains are just compiler settings that cl.exe reads. (You can technically install the MSVC toolset separate from Visual Studio, but nobody I know of actually does that.)

CMake is just another frontend that can build those .sln files. Once those are created, you can just run cmake --build ., and that will kick off the Microsoft compiler. That same command cmake --build . on Linux would kick off GCC.


[edit]
When writing plugins, you’ve gotta use the same compiler as the main software. Maya 2016 was compiled using VS2012, and therefore you have to compile plugins using VS2012. Maya 2017 required VS2015, and Maya 2020 requires VS2017. Maya 2020 on Linux uses GCC 6.3.1. I don’t know the other version requirements for Linux off the top of my head.
You can sometimes get away with using newer compilers, but that’s not always a guarantee.

And there are certainly other compilers that exist (like CLang or LLVM), but as far as I know you can’t compile Maya plugins with those.

1 Like

Thanks all for the replies. I was frustrated loosing a Saturday morning to Visual Studio’s mysteries.
(looking at the microsoft gltf SDK) upgrading to a new version cleared up the immediate build failures, I gathered form stackoverflow there are some Visual C++ files that the older version did not have.

I can see why people choose to skip Visual Studio all together. I’ve used VS code setups, and the .bat solution using then Microsoft Developer prompt, and they are indeed more pleasant to work with

But here at my studio the engine programmers use Visual Studio. If I am to nudge my career in the direction I intend I will be interacting with the game code more and more so It behooves me to understand the beast. Luckily I have co workers and colleagues to bother about it.

I would like “cut and paste the error into stack overflow” to not be my default solution…maybe that’s what every does any way, lol

More serious now:
Fair enough. If you’re dealing with games, you’re probably dealing with Windows, so most of the cross-platform issues go away, and you can always upgrade or downgrade the toolchain in VS.

The biggest trick I learned in VS was how to deal with layering Property Pages so I could switch between targeting different versions of Maya just by swapping out different pre-created pages in different build targets.

But when trying to compile somebody else’s code: There is unfortunately no shortcut through dependency hell that I know of (vcpkg helps though). Heck, it took me at least a week to just get Alembic compiling on my machine, and I feel like I did a pretty good job. I know people whose job is to do nothing but set up the compilers. It’s not an easy thing.

1 Like

Thanks again for replying. I’m making some headway with the Microsoft gltf sdk code and getting it into a maya plugin. Luckily our programmers are happy to share knowledge. It seems like ag chunk of visual studio issues are just coping with the variable project setups that people use. But I do think dealing VS project properties to cope with variable structures is arcane and maybe a holdover from the old days

Hey Mambo4,
You probably have seen this, but just incase theres a Cult of Rig playlist here that could be of some use:

1 Like

Yes this Visual Studio series is excellent. Approaching it form a “what goes wrong and how we fix it” direction is fantastic. I also learned a lot form Casey Muratori over at Handmade Hero. Even Casey avoids VS like the plague, except the debugger, his explanations of how C compiling works is great.

I guess It’s more about wrapping my head around VS’s organizational paradigms, distinguishing what is crucial to a C/C++ project and what is an arbitrary assumption that VS makes. Is it breaking because The code is flawed or technically organized wrong, or is it because there is a structural VS assumption I am failing to meet?

I suppose it is much like the early days of learning any complex software like Maya or Max or even Photoshop: when something goes wrong you have no idea why or how to fix it. Only after struggling, googling, posting on forums, and solving the problem a few times does the process become clear.

3 Likes

Here is a current example.

I recently renamed a some source files and functions, now I’m trying o debug my project , which compiles just fine, but on attaching and debugging, generates a Mel Script error in the script editor. setting a break point and running the debugger gives me this.

image

CommandEngine.pdb does not exist on my machine, and from the Autodesk forums It appears it is not supposed to be there. So, why on earth is Visual studio complaining about it? How can I tell VS to stop looking for it? Or Is the Autodesk forum post in error? How am I supposed to know?

Autodesk does not release the CommandEngine.pdb files (or any of its own .pdbs)

I googled that I could set VS to disassemble machine code instead. doing so, I noticed that in the call stack was a lot of Python27.dll. I thought “Why is python being invoked?” Then I thought “Maybe the gltf JSON is involved.”

I checked the gltf json data and it was pointing to a .bin resource that did not exist. ( Python27.dll probably has nothing to do with it: those stack calls were likely my own testing UI)

Well that was a case of “the problem you see is not the problem you have”.

Coming from Python I would expect some kind of “your data is bad” error, but I guess in compiled C++ land you have to code your own such things.

The issues you are facing are with c++ rather than VS.
VS does its best to wrangle the madness of c++ together. c/c++ are old languages and their structure and expectations are pretty archaic, but it also let’s you do just about what ever you want which is more a hindrance than a help as it can be super confusing ( the reason python was created, with its only one way to do something approach )
My suggestions:

  • Try and ignore the majority of the VS features as it is overload if you are just doing a plugin for Maya.
  • Setting up your environment and project settings can be easier if you manually edit the project files. You can set up variables then, which can really help simplify the process.
  • if you are working with a bunch of VS users, ask them for help. In my experience, coders love to explain stuff like this ( how I learned that c/c++ is bonkers to begin with )

Ultimately, searching for stuff is the only other alternative - stack overflow is a life saver, even if it feels it can be a cheat to use it.

I can’t agree 100%, having done c/c++ projects in linux and in VS Code, I find VS much more obtuse and frustrating. the previous .pdb error being a good example. But your point about ignoring most of the features is valid.

Although like anything you get better at grappling with VS the more you do it. it took a few failed project builds to give me a sense of where to look for what build errors. My main issue is that VS is little help to a novice in addressing those failures. I mean the bigger picture stuff “when you see errors like that, you need to look here, and consider this structural aspect of your code” Raffaele’s tutorial above is the only such thing I have seen that addresses the challenges of building in VS from practical higher level standpoint

as for manually editing the project files, do you mean editing directly the .vcxproj xml?

I find VS much more obtuse and frustrating

I will amend my statement, c/c++ is bonkers on windows. If VS ran on Linux it would be a lot less confusing purely because Linux doesn’t have the same issues as windows re dependencies and versioning.
Ultimately tools and their usefulness are a matter of personal preference I guess.

do you mean editing directly the .vcxproj xml?

Yes, realising this made life a lot easier for me on my lost project supporting 2 different versions of 3DsMax from the same project.

I would say not to dismiss VS because it is a very widely used tool in multiple disciplines and industries, so it is worth the struggle - this is coming from someone who only learned VS & c++ the past few years.

This article was a great reference for me, but it is focused on 3DsMax - you might still find it useful: