I'm not a great Visual Studio expert so this took me some time to figure out, and I must warn you that not everything in this article may be 100% correct. But I hope my findings can be useful anyway, and I will update the article when someone points out where I'm wrong.
So, we had a problem debugging the standard C# project called Microsoft.Dynamics.Ax.Tms. No matter what we tried and how we tried it, we just couldn't get the debugger to load any symbols for the DLL and thus we couldn't get Visual Studio to hit any breakpoints for our debugging session.
The problem is somehow related to the fact that the location of the symbol file (.pdb) is stored within the standard C# project. So in this case Visual Studio is looking for the symbol file in what seems to be a path on some Microsoft internal development server. See the original location here:
You can see the above windows when you have attached the debugger to the AOS process and you activate the Debug / Windows / Modules window, and click on the Microsoft.Dynamics.Ax.Tms module. This is also where you can load the symbol file manually (which I'm about to try to do in the above screen shot - that approach didn't work however).
To get a new symbol file that matches the actual compiled DLL and that can be found in a folder on your system, you need to make a (any small) correction to the C# code, which triggers that you get a new symbol file during compilation. You need to deploy the newly compiled DLL with your change to the AOS, following the existing guide lines for that.
Now in the debug window of a new debug session, you can see that it has loaded the new DLL from the AOS together with the newly created symbol file of your Visual Studio project.
And now you can debug.