We Keep Coding

C# Visual Studio Service Debugging "The breakpoint will not currently be hit. No Symbols have been loaded for this document"

New to Visual Studio and new to C#. Building a C# windows service called Transactional Messaging in Visual Studio 2017, which is dependent on a project called Outbound Messaging. When I start debugging and try adding breakpoints on the Outbound Messaging files, I get
"The breakpoint will not currently be hit. No Symbols have been loaded
for this document"
From what I can tell, VS is only unable to load the pdb files for: log4net.dll, Castle.Windsor.dll, and Castle.Core.dll. I don't have this issue with adding breakpoints to files in the Transactional Messaging Service. I haven't been able to identify behavior patterns or a permanent fix, so at this point the error seems random. One minute I think I've found a fix, and when I try using that fix on the same error later in the day I have no luck. I am suspicious of a recent power outage that shut my computer down unexpectedly since it looks like pdb files can be cached, but have been told that would be a long shot.
Steps I follow to debug the service:
Stop Transactional Messaging Service via windows services applet
Uninstall Transactional Messaging Service via VS command line using installutil /u TransactionalMessaging.exe in the Debug folder
Clean Transactional Messaging Solution in Visual Studio
Build Transactional Messaging Solution in Visual Studio (at one point a fix was to right click on each aspect of the solution in the solution explorer and build that individually)
Install the Transactional Messaging Service via VS command line using installutil TransactionalMessaging.exe in the Debug folder
Start the Transactional Messaging Service via windows service applet
In VS, Debug > attach to process > Transactional Messaging
Try adding breakpoints to files in Outbound Messaging service which gets me the above error.
Steps I've tried to solve this error:
Debug > Windows > Modules to manually load each module's symbols (pdb files for log4net.dll, Castle.Windsor.dll, and Castle.Core.dll cannot be found)
picture of modules
Completely delete bin and obj folder between steps 2 and 3 above
Project > Project properties > Build > Advanced > Debugging Information: full (for both Transactional Messaging and Outbound Messaging)
I'm not sure if this is a lack of understanding of VS, C#, or the code base. Any insight is appreciated, I'm past the googling stage and posting a new question as a last resort.

I usually get this message when I have changed code in a project A and forgot to compile it.
The other project B, which references project A, has the up-to-date source code of A on the screen, but started with an outdated assembly of A. So it cannot enable breakpoints because the code does not match the assembly.
There's one more thing, which in my opinion is a bug and a pain in the ass, but according to MS is by design (I have asked them):
Since Visual Studio 2015, the compilation of project B does NOT automatically include modified referenced assemblies, which in this example is assembly A. There is a local copy of A somewhere in B, which is used instead. Same result as above: up-to-date code, but outdated assembly.
Instead of compiling, you have to rebuild it!
There's another one more thing:
You have to compile for DEBUG mode. In Release mode, the default project settings do not allow proper debugging, like they did in VS 2008 for example.

You can not attach the debugger, because you are lacking the right to do so. You can get this right only be flipping a certain bit in the registry.
See my earlier Answer:
Also start VisualStudio as Administrator and allow, that a process can
automatically be debugged by a different user:
reg add "HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f

If nothing help from above than make sure your files are open from the relevant project, not from another (old) one.
Example:
You working on a project, close the VS, but you left files (tabs) open in VS.
Copy your project to a new folder and open solution. The files (tabs) will load from the old directory and if you want to debug then you cannot debug until you close them and reload them from the current folder.
I was very close to reinstall my VS because nothing helped for me from another answers, but fortunately I realised this in my project and I can debug now.

Unable to see the code and design in visual studio

I accidentally deleted my project from visual studio2013/projects/myproject. I did a system restore and got the folder myproject. I am unable to see my code form or design form but I can run my application.
What d I have to do to be able to edit my code?

System Restore will only revert the computer's state (including system files, installed applications, Windows Registry, and system settings), not user files, and your sourcecode files are user files.
Since you can still run the application, then you must have a compiled executable somewhere. I suggest that you download dotPeek from JetBrains and then you can open your application up in it and decompile your assembly back into source code.
The code will be a bit ugly; your nice, meaningful variable names will probably be gone, but at least it's a starting point. Here's the link to dotPeek. https://www.jetbrains.com/decompiler/
BTW, I'm assuming that you've already tried to get the files back from the Recycle Bin.

Cannot debug under Visual Studio Express anymore

I used to be able to debug using Visual C# Express 2010 with no problem before. However, since I've opened my project using MonoDevelop (to port it under MacOS), I can't seem to be able to debug anymore.
The exact error message is available below:
A lot of people says to go in the configuration manager, which I'm familiar with, however, I can't seem to find it in the Express version.

Since you didn't have this issue prior to opening in Monodevelop, it more than likely changed something within the solution and/or project files. There are a number of posts on stackoverflow...
stackoverflow: no symbols
stackoverflow: no symbols when crossing module boundries
(From Răzvan Panda comment on the question)
... that talk about missing symbols. However, based on the information provided about monodevelop, I'd venture to guess that the IDE changed something within the solution and/or project files.
If your solution is under source control and you don't see any differences in these files, let me know. Otherwise, you could create a new blank solution/project file (from Visual C# Express 2010) and re-add all your files to it to get the default settings back and see if that resolves your issue.
EDIT: Also, keep in mind that there are ".user" files that I guess "might" have an effect on build/debugging configurations. If re-adding your files to blank solution/project files doesn't work make sure all the "extra" files like ".user" are not in the directory. Usually files like ".csproj.user", and ".suo". I've never had an issue deleting these they store local configuration changes that are not usually checked into source control.

I had same problem with Symbols when I added some dll to my project so what I did was to manually adding them. you can try going to tools > option > Debugging > Symbols and from there you can add the file root (in this case monoDevelop) and it automatically looks for all .pdb files and adds them to your environment. After rebuild it should be Okay.
Cheers

As George Duckett said:
Re. configuration manager, enable expert settings first. Tools->Settings->ExpertSettings. Then find it under Build->ConfigurationManager
Then changed it to Debug.

How licenses.licx file is used

I've got licenses.licx file that is included to one of my projects properties. I am not sure how that is used by its dlls. Is it used by msbuild? Do you have any idea how it is used when the solution is building?

Since you indicate that StellarEleven's reply doesn't help, I guess you're looking for something even simpler. This is probably not 100% correct, but it is my understanding of how this works:
The licx file is simply a list of the "licensed" components used by your application.
Each line in the file is of the following format:
[Component Name], [Assembly Name]
For example one of my projects uses the licensed IP Works NetDial component so my .licx file contains the following line:
nsoftware.IPWorks.Netdial, nsoftware.IPWorks
In the context of the project (.csproj) file, the .licx file is referenced as an EmbeddedResource. During the build process, LC.exe verifies that the machine performing the build has the appropriate license(s) for the component in question, and generates a binary .licenses file which eventually gets embedded as a resource ([AssemblyName].exe.licenses) in the final executable.
Does this help?

Licenses.licx file woes
File this under ASP.NET, Department of WTF.
Frustration When you are developing a web application with our
controls, a mysterious file called licenses.licx appears. No, it's not
an order to use a weirdly-named lollipop, but is a transitional file
generated (and modified) by Visual Studio that participates in license
checking. In design mode, Visual Studio uses this file to make a note
of every licensed control you use in your design. When you then build
your application, Visual Studio read this licenses.licx file and for
every control mentioned there, will load the relevant assembly and run
the license code in that assembly to see if the assembly is properly
licensed (that is, that the product to which it belongs has been
properly installed on that machine). If everything checks out, Visual
Studio embeds the license key into the executable. If it doesn't,
you'll get weird error messages about the control not being licensed
(my favorite is "Could not transform licenses file 'licenses.licx'
into a binary resource." to which I usually invoke the colorful
language of my ancestors).
Licenses.licx is actually a file in your solution (if you cannot see
it there, click Show All Files). Visual Studio uses a program called
lc.exe to compile the licenses into embedded resources in your
application, and when things go wrong with the license compiling I've
seen error messages that reference this executable as well.
Here's an example of a line in a licenses.licx file.
DevExpress.XtraCharts.Web.WebChartControl,
DevExpress.XtraCharts.v8.2.Web, Version=8.2.4.0, Culture=neutral,
PublicKeyToken=9b171c9fd64da1d1
The first value in this comma delimited list is the class, the second
is the assembly where it's found, and the other values are the rest of
the assembly's strong name. I'm sure you can see problems already,
especially when you upgrade a solution to the latest versions of the
third-party controls you use. If you want, you can edit this file and
remove the strong name parts with no problem.
But that's not the biggest issue with licenses.licx. The thing is
Visual Studio has a propensity of touching this file if you open the
solution (that's "touching" as in changing the file date to the
current date/time). This plays havoc with licensing, especially if you
happen open the solution on a non-licensed machine and you are using
source control. Suddenly your build machine will throw off these
"cannot transform" messages and you're left wondering what went wrong.
Another prevalent issue is when you have a team of developers working
on a solution: they're all unconsciously "modifying" this file.
So, the answer seems to be not to put the licenses.licx file under
source control. (KB article)
But this solution to the problem throws another red flag: if one of
the developers in a team adds a new control that needs licensing to
the form, a line gets added to his local licenses.licx file and it may
not get reflected in source control. Bam, your build machine fails the
build and Joe, who added the control, has to buy doughnuts for the
team until someone else breaks the build.
I'm afraid I have no good solution to this latter issue, because
unfortunately the "not putting licenses.licx in source control" seems
to be the way everyone is solving the licensing problem. Another
solution is to delete the licenses.licx file altogether and then get
Visual Studio to regenerate it by opening the solution (although this
is a bit difficult on a build machine).
Anyway, hope that all helps in some way. And hitting your laptop with
a phone isn't really going to help.

We use a custom check-in policy (TFS) that explicitly nulls the contents of this while if present in the check-in list.

Breakpoint not hooked up when debugging in VS.Net 2005

Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.

Maybe this suggestion might help:
While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
Look for your project's DLL, and check the Symbol Status for it.
If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
I've found that it's sometimes necessary to:
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.

http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/

In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.

Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?

Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.

I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.

AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.

Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).

Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.

In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]

Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?

Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?