I have a problem with c# settings...
I have a string in Setting and call it UserStr
when I debug my program, I can change and use it without any problems:
using it:
var str=Properties.Setting.Default.Userstr;
changing it:
Properties.Setting.Default.UserStr="SomeTextbox.Text";
Properties.Setting.Default.Save();
and it works fine...
but when I run the debugged program from debug folder,the value of UserStr is the default value I set in first place...
Am I doing anything wrong?
Am I doing anything wrong?
No, this is just how the debugger works. You likely have the Visual Studio hosting process enabled (it is enabled by default). The settings manager uses the .exe as the key for the directory where the settings are stored.
The result of this is that you actually have two different settings files. One that's used when you run the program standalone, and one that's used when you run the program under the debugger, because in each case a different process .exe is actually what's running.
In many cases, you can live without the hosting process. It can be disabled in the project settings, under the Debug tab. Uncheck the checkbox labeled "Enable the Visual Studio hosting process". If you do so, then even when debugging the process .exe will be your actual program, and it will use the same settings file as when the program is used standalone.
Personally, I'd leave things as they are. I don't usually find it a problem to have two different settings files in use. I typically am not running the program standalone until debugging is, for the most part, over with.
See What is the purpose of vshost.exe file? for more details.
Just try:
Properties.Settings.Default.Reload();
I'm unable to debug a project. I'm getting the "The breakpoint will not currently be hit. No symbols have been loaded for this document" error. I've tried everything I could find online, but nothing has worked. I'm hoping someone out there will be a fresh pair of eyes to find the problem.
First of all, I inherited this project from a coworker who has left. He did development on his machine where he was able to debug it. He uploaded it to Subversion which is where I got it. Another coworker was able to download it and debug, but I cannot.
Second, I'm using Visual Studio 2015. The project is an asp MVC project. There are two projects in the solution: the main project with the views, controllers, models, etc. and the secondary project which is only the Telerik.OpenAccess code (the "data layer"). It's this secondary project that I can't debug.
* Update *
Following a suggestion on another board, I hit a break point in my main project and went to Debug-Windows-Modules where I can see the message "Binary was not built with debug information". I went to the folder shown and can see my pdb file was not made at the same time as my latest dll fill. My project is set to debug mode and build. What do I need to change to get the pdb file to be recreated along with my dll?
* End Update *
So here's the line in the main project I've got my breakpoint:
rep.UpdateWorkOrderVendorHeader(oaObj);
The breakpoint hits here. It's calling a function in the secondary project. When I try to step into that function, it skips to the next line in the main project. If I look in the secondary project, I see the "symbols not loaded error". I also have a breakpoint directly inside the secondary project and still it gets skipped:
I've found two stackoverflow streams that covered a variety of scenarios, but nothing has worked for me:
Fixing "The breakpoint will not currently be hit. No symbols have been loaded for this document."
The breakpoint will not currently be hit. No symbols have been loaded for this document in a Silverlight application
Here is everything I think I've tried so far, but I may have missed something:
Restarted Visual Studio
Deleted code and copied code from co-worker that could debug secondary project
Build - Clean and Rebuild & Clean and Build
Deleting bin and obj folders
Checked configuration set to debug and build
Checked debug and trace constants are checked in the project properties
Click Debug - Start new instance on secondary project
Selecting multiple startup project (threw error saying the secondary project could not be started directly)
Debugging in IE instead of Chrome
Checked the reference to the secondary project in the main project has the correct directory
Checked that Project - Properties - Build - Optimize code was unchecked
Checked that Project - Properties - Build - Advanced settings were the same for both projects
Checked that Project - Properties - Build - Advanced - Output was set to full
Adding to the secondary project's App.config
Making sure I was running Visual Studio as administrator
Checked that Project - Properties - Build - Output path was /bin
I'll include seem screenshots of the config and properties below. Below is also a description of my project tree with some of the relevant files. I'd appreciate any suggestions you can give me. Thank you!
Koorsen (main project)
References
Koorsen.OpenAccess (secondary project)
C:\inetpub\wwwroot\Koorsen\Koorsen.OpenAccess\bin\Debug\Koorsen.OpenAccess.dll
bin
Koorsen.dll
Koorsen.pdb
Koorsen.OpenAccess (secondary project)
bin
Debug
Koorsen.OpenAccess.dll.config
Koorsen.OpenAccess.pdb
Koorsen.OpenAccess.dll
Telerik.OpenAccess.35.Extensions.dll
Telerik.OpenAccess.35.Extensions.xml
Telerik.OpenAccess.dll
Telerik.OpenAccess.xml
Release
Koorsen.OpenAccess.dll
Koorsen.OpenAccess.dll.config
Koorsen.OpenAccess.pdb
Telerik.OpenAccess.35.Extensions.dll
Telerik.OpenAccess.35.Extensions.xml
Configuration Manager:
Build properties:
Advanced debug properties for main project:
Advanced debug properties for secondary project:
Didn't receive an answer, but I was able to figure this out over a couple of days of trial and error. Posting this here in case it helps someone. Here is what I ended up doing.
Put a break point in the main project and ran the solution. When it hit the break point, I went to Debug->Windows->Modules. Found the name of the dll for the secondary project and noted the folder it was trying to use. I my case it was in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\213421ba\66682af2\assembly\dl3\e121f20c\957624fe_d9ded101. The dll and pdb files did not have the same date. Rebuilt the project; the dll was updated, but not the pdb. Found a suggestion in another forum suggesting deleting the dll and pdb and rebuilding. This didn't work; the dll was recreated, but not the pdb. I deleted the entire vs folder.
Used NuGet package manager to uninstall and reinstall 2 Telerik Data Access packages to all projects.
Deleted the bin and obj folders in the secondary and main projects. May have been able to get away with just doing this in the secondary project.
At this point the secondary project compiled, but the main project did not.
Had to add some dll files back to the bin folder of the main project from third party extensions.
Still would not compile. Compared every reference, bin and obj file to those of a coworker who was having the same problem, but hadn't tried to fix being able to debug yet. Found 3 extra references. Removed them and the project worked again and I was able to debug the Telerik Open Access project.
I have an application that reads from a user settings file, typically stored in Users/{username}/AppData/Local/{publisher}/{app}/{version}/user.config. I want to test making changes directly to the file, not through the Visual Studio properties editor.
I found this answer to a different question that points to where the application is supposedly loading the file from, but it doesn't seem to exist when I check during a debug session in Visual Studio.
For example, when I run the following in the Immediate window when stopped on a breakpoint, it fails to find the file.
System.IO.File.Exists(System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath) //returns false
My reason for wanting to find this file during debugging is that I have received reports of the config file being corrupted and crashing the application in production. I'm sure that I can return that file to a default state, but I want to actually reproduce the problem in a debug environment.
How can I find the settings file loaded by Visual Studio?
I'm not quite sure what changed between when I posted this question and now, but today the code in my question returns true. But to answer the specific question I asked, the user.config file was in a very similar path to a standard installed application.
Standard application:
Users/{username}/AppData/Local/{publisher}/{app}/{version}/user.config
Visual Studio debug application:
Users/{username}/AppData/Local/{publisher}/{app}.vshost.exe{some_hash_value}/{version}/user.config
there:
The Application is build from C#, and the Dll is built from C++, and they are in different solution. When I Launch the Dll's debugger, there is always a message box pop up, which says "Debugging information for 'App.exe' cannot be found or does not match.Skipped loading symbols for NGen binary."
Thanks.
p.s. I've try putting the App.pdb in several location, but still don't work.
As commented by ortang, you need to activate the debug info when building your project.
See "/DEBUG (Generate Debug Info) (Visual Studio 2013)":
The /DEBUG option creates debugging information for the .exe file or DLL.
The linker puts the debugging information into a program database (PDB). It updates the PDB during subsequent builds of the program.
It is not possible to create an .exe or .dll that contains debug information.
Debug information is always placed in a .pdb file.
To set this linker option in the Visual Studio development environment
Open the project's Property Pages dialog box. For details, see Setting Visual C++ Project Properties.
Click the Linker folder.
Click the Debugging property page.
Modify the Generate Debug Info property.
This is driving me crazy.
I have a rather large project that I am trying to modify. I noticed earlier that when I typed DbCommand, visual studio did not do any syntax highlighting on it, and I am using using System.Data.Common.
Even though nothing was highlighted, the project seemed to be running fine in my browser. So I decided to run the debugger to see if things were really working as they should be.
Every time the class that didn't do the highlighting is called I get the "the source file is different from when the module was built" message.
I cleaned the solution and rebuilt it several times, deleted tmp files, followed all the directions here Getting "The source file is different from when the module was built.", restarted the web server and still it tells me the source files are different when they clearly are not.
I cannot test any of the code I have written today because of this.
How can the source be different than the binary when I just complied
it?
Is there any way to knock some sense into visual studio, or am
I just missing something?
I got this issue running a console app where the source that was different was the source that had the entry-point (static void Main). Deleting the bin and obj directories and doing a full rebuild seemed to correct this, but every time I made a code change, it would go out-of-date again.
The reason I found for this was:
I had checked "Only build startup projects and dependencies on Run" (Tools -> Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, my start-up project didn't have "Build" checked
(For #2 -> accessible via the toolbar under the 'Debug/Release' drop down list.)
I was just having this same problem, my projects were all in the same solution so they were using Project to Project references, so as one changed the others should have been updated. However it was not the case, I tried to build, rebuild, close VS2010, pulled a new copy from our source control. None of this worked, what I finally ended up trying was right clicking on the project and rebuilding each project individually. That updated the .dlls and .pdb files so I could debug through.
The issue here is that your dll and or your pdb files are not in sync.
Follow these steps
Just delete the bin directory from the project where the DLL is generated.
Re-build the project.
Remove reference from the project that make reference to the DLL.
Include again the reference.
Enjoy.
In addition to these answers I had the same issue while replacing new DLLs with old ones because of the wrong path. If you are still getting this error you may not refer the wrong path for the DLLs. Go to IIS manager and click the website which uses your DLLs. On the right window click Advanced Settings and go to path of the Physical Path folder on File Explorer and be sure that you are using this folder to replace your DLLs.
Some things for you to check:
Have you double checked your project references?
Do you have a Visual Studio started web server still running? Check the system tray and look for a page with a cog icon (you may have more than one):
(source: msdn.com)
Right click and close/exit it. You may have more than one. Can you debug your changes now?
Are you running the debug version but have only built the release version (or vice versa)?
Did the compile actually succeed? I know I've clicked through the "there were errors, do you want to continue anyway?" message a couple of times without realising.
With web services, the problem can be caused by using the Visual Studio "View in Browser" command. This places the service's DLL and PDB files in the bin and obj folders. When stepping into the web service from a client, somehow Visual Studio uses the PDB in the bin (or obj) folder, but it uses the DLL in the project's output build folder. There are a couple workarounds:
Try deleting the DLL and PDB files in the web service bin and obj files.
Try clicking "View in Browser" in Visual Studio.
If you previously got the source file mismatch error, Visual Studio might have added the filename to a black list. Check your solution properties. Choose "Common Properties -> Debug Source Files" on the left side of the dialog box. If your web service source files appear in the field "Do not look for these source files", delete them.
Unload the project that has the file that is causing the error.
Reload the project.
Fixed
I just had this issue.
I tried all the above, but only this worked:
delete the .pdb file for the solution.
delete the offending .obj files (for the file being reported out of sync)
build the solution.
This fixed the issue for all builds moving forward for me.
In Visual Studio 2017 deleting the hidden .vs folder in the resolved this issue for me.
This is how I fixed the problem in Visual Studio 2010:
1) Change the 'Solutions Configurations' option from "Debug" to "Release"
2) Start debugging
3) Stop debugging and switch the 'Solutions Configurations' option back to "Debug"
This worked for me. Step 3 is optional - it was working fine when I changed it to "Release" but I wanted to change it back.
My solution:
I had included an existing project from a different solution in a new solution file.
I did not notice that when the existing project was rebuilt, it was putting the final output into the NEW solution's output directory. I had a linker path defined to look into the OLD solution's output directory.
Switching my project to search in the new solution's output directory fixed this issue for me.
I had this problem, and it turns out I was running my console application as a windows application. Switching the output type back to console fixed the issue.
I had the same problem. To fix it I used the "Release Mode" to debug in VS2013. Which is sufficient for me, because I'm working in a node js\c++ addon.
My problem was that I had two projects in my solution. The second one was a test project used to call the first one. I had picked the path to the references from the bin folder's release folder.
So whenever I made a change to the first project's code and rebuilt it, it would update the dlls in the debug folder but the calling project was pointing to the release folder, giving me the error, "the source file is different from when the module was built."
Once I deleted the reference to the main project's dll in the release folder and set it to the dll in the debug folder, the issue went away.
In my case, the #Eliott's answer doesn't work.
To solve this problem I had Exclude/Include From Project my deficient file, andalso Clean and Rebuild the solution.
After these actions, my file with my last modifications and the debugger are restored.
I hope this help.
solution:-
the problem is:-
if your some projects in a solution , refer to some other projects,
then sometimes the dll of some projects, will not update automatically, whenever you build the solution,
some projects will have previous build dlls, not latest dlls
you have to go manually and copy the dll of latest build project into referenced project
I was using Visual Studio 2013 and I had an existing project under source control.
I had downloaded a fresh copy from source control to a new directory.
After making changes to the fresh copy, when building I received the error in question.
My solution:
1) Open Documents\IISExpress\config\applicationhost.config
2) Update virtualDirectory node with directory to the fresh copy and save.
My problem was that I had a webservice in the project and I changed the build path.
Restoring the default build path solved my issue.
I had this same problem and I followed the majority of the guidance in the other answers posted here, nothing seemed to work for me.
I eventually opened IIS and recycled the application pool for my web application. I have IIS version 8.5.9600, I right-clicked my web application, then: Deploy > Recycle > Recycle application pool > OK.
That seems to have fixed it, breakpoints now being hit as expected. I think that doing this along with deleting the bin and obj folders helped my situation.
Good luck!
I know this is an old question but I just had the same problem and wanted to post here in case it helps someone else. I got a new computer and the IT dept merged my old computer with the new one. When I set up TFS, I mapped a different local path than what I was previously using, to an additional internal drive. The old path still existed from the merged data on my hard drive so I could still build and run. My IIS paths were also pointing to the old directory. Once I updated IIS to the correct path, I was able to debug just fine. I also deleted the old directory for good measure.
I also experienced that. I just open the obj folder on the project and then open the debug folder delete the .pdb file and that's all.
This error also happens if you try to make changes to a source file that is not part of the project.
I was debugging a method from a .dll of another one of my projects, where Visual Studio had quite helpfully loaded the source because the .dll had been built on the same machine and it knew the path to the source. Obviously, changing such a file isn't going to do anything unless you rebuild the referenced project.
Delete all breakpoints.
Rebuild.
Done
At Visual Studio 2015, using C++, what fixed for me the the source file is different from when the module was built problem was
restart Visual Studio.
Check if the location you pointed to using mex() in Matlab is correct (contains lib and obj files which are modified to the last date you compiled the library in Visual studio).
If this is not the case:
Make sure you are compiling Visual studio in a mode that saves .lib files :
properties -> Config properties -> General -> Config type -> static library
properties -> Config properties -> General -> Target extension=.lib (instead of exe)
Make sure the output and intermediate directories match the Matlab directory in
properties -> Config properties -> General -> Output directory
properties -> Config properties -> General -> Intermediate directory
I get this issue when debugging sometimes w/ Visual Studio but when the application is served by IIS. (we have to develop in this form for some complicated reasons that have to do with how the original developer setup this project.)
When I change the file and rebuild, that fixes it a lot of the time. I know that sounds silly, but I was just trying to debug some code to see why it's doing something weird when I haven't changed it in a while, and I tried a dozen things from this page, but it was fixed just by changing the file..
In my case, the problem was that the debugger exe path was pointing to a net5.0 bin folder. I am using net6.0, so I should've updated the exe path back when I updated the target framework. Works fine now.
Debug-> start without debugging.
This option worked for me. Hope this helps!