VS2010 c#, winforms project.
It does not build automatically when I click on debug or press f5. If I manually build the project before I debug, it compiles and changes are picked up.
My other projects all work as expected. Why doesn't it build automatically?
Right-click the Solution (not project) in the Solution Explorer and select Configuration Manager. Check if Build is turn off for the current configuration.
Check your settings in Tools->Options.
Go to the projects and Solutions area, Build and Run page.
There is a setting "On Run, when projects are out of date:" Make sure this is set to 'Always build.'
I ran into this same issue and I did the following:
Run Build Clean
Close the solution
Delete any .suo and .user settings files
Delete any .ncb files
Open the solution again
Unload the project
Reload the project
Make sure the project is set as startup again
Debug away!
You may be able to only do steps 6-9 but I don't know how to get back in that state.
Because my project was independend from other projects by using prism I had to uncheck 'Only build startup projects and dependencies on Run' in Tools->Options->Projects and Solutions->Build and Run.
When you work on a dependency
In my case, I am working on a library used by an executable.
It was necessary to say to the solution to include the dependency of the library in the executable project solution to build the executable code and the library code before launching the debugging:
Tools Menu, click on Options. Go to "Projects and Solutions/Build and Run", "On Run, when projects are out of date" needs to be on "Always build".
Right-click the Solution (not project) in the Solution Explorer and select "Project Dependencies". Check the boxes of dependencies "Lib1" and "Lib2".
Just in case someone else runs into the same problem as I did: for me it turned out to be a setting in my web.config as follows:
<httpRuntime fcnMode="Disabled" targetFramework="4.5" maxRequestLength="40960" executionTimeout="1200" requestValidationMode="2.0" />
What this guy does is he disables File Change Notification, which is used to restart the application domain when a change is detected in critical files e.g. anything in the bin or .config files. Without fcn, I would make code changes, press F5 and still see the old code, and all breakpoints would be whited out because the source was different to what IISExpress was serving up.
I had a similar situation with multiple projects in a solution in Visual Studio 2013. One of the projects that the Startup project uses was not building when I clicked the Run button. I had to right-click on the Startup project and select "Build Dependencies" and check the project that wasn't building in there.
Was scratching my head on this for a while, turns out our office's Folder Redirection configuration (e.g. My Documents to point to a Network location) did not integrate well with VS.
I wanted to switch from gDEBugger to CodeXL as CodeXL is the successor of gdeb and even has Visual Studio integration.
However, there are some problems with the integration for me. I'm using VS2013, the most recent CodeXL version and compile against .NET 4.5.
It starts the executable from the obj folder, not the bin folder. Thus, if I start CodeXL debugging, it doesn't find my engines DLL or any other stuff copied with the output, as these reside in the bin folder. I fixed this by manually copying the files there, but that's a rather dirty solution if you ask me.
I don't know how to log CodeXL redundant state changes with CodeXL, the thing I used gDEBugger mostly for. I can only start my project in the CodeXL "Debug Mode", but this one doesn't log redundant state changes. If I switch to the required "Analyze Mode", I don't get any statistics at all and can't even start the application, buttons and the statistics view are disabled.
Is someone successful using CodeXL with OpenTK and can tell me how to proceed? It boils down to the following two questions:
How to change the executable path to correct the obj <-> bin folder problem?
How to log redundant state changes of the OpenGL application?
This is not a perfect solution but would ensure you have the latest files every time you build inside your "obj" folder, you could go into your project properties and under "Build Events" set your "Post-build event command Line:" to:
copy "$(SolutionDir)\YourProjectName\bin\Debug" "$(ProjectDir)\obj\Debug"
Assuming of course your active build is set to "Debug" and also replace your "YourProjectName" with your project name :-)
after compiling a simple console application project for release I get a lot of output:
The .exe => thats fine, I need this for sure :)
MyApp.exe.config => Im using and changing this, thats fine
Some .dll files => these are the extern libraries Im using, I think thats fine too
Unknown:
MyApp.pdb
MyApp.vshost.exe
MyApp.vshost.exe.config
MyApp.vshost.exe.manifest
log4net.xml => huh, the config for log4net is already in MyApp.exe.config, why is another log4net config xml here?
Can I delete some of them without getting later trouble? Can I add the .dll´s somehow into the .exe (so that I dont have to copy always all the .dll with the .exe)?
This is expected, and all have purposes - but you are right: you don't need any of the "unknown" files, and can delete them (and certainly don't need to distribute them). For info:
MyApp.pdb is the debug symbols; useful for stacktrace, and for debugging later if problematic; you can disable this via the Debug Info option in the Advanced Build Settings dialog (Project Properties, Build, Advanced...) but I don't recommend it
MyApp.vshost.* is the debugger host process; you can disable this by disabling the "Enable the Visual Studio hosting process" option (Project Properties, Debug)
log4net.xml is the intellisense comments - useful for IDE usage when adding references
Those files aren't meant to be distributed to client pcs nor are useful for app to work properly: they're there (also) for debugging purpose.
If you want to "merge" dlls to your project, try using Microsoft utility ILMerge.
When you build your solution in release configuration there will be no *.vshost.*., this is an executable for debug hosting process.
log4net.xml you can remove, I believe.
You should be fine deleting/not deploying most of them.
If the dll's are managed assemblies you can use IlMerge which will add the dll's into the exe for you.
i got a problem with my site with my app_code files and a lot of question ive read people say you need to change the proprties of the .cs files to Build Action.
by right clicking the .cs files and press proprties.
but...
when i right clicking the files i cant see any option called proprties so i press F4 and it open a proprties window and i just click on the .cs file and still cant see any option i can change somthing to Build Action.
any idea why i cant see this options?
EDIT:
my problem is that when i get in the file proprties i have only 2 options...
thay are called:
1.Full Name
2.Full Path
EDIT2:
here what i see in visual studio 2010 when i try access the protrtie menu/window
http://img338.imageshack.us/img338/2359/blac.png
As Microsoft points out in the article "Web Application Projects versus Web Site Projects":
Web application projects use Visual Studio project files (.csproj or
.vbproj) to keep track of information about the project. Among other
tasks, this makes it possible to specify which files are included in
or excluded from the project, and therefore which files are compiled
during a build.
An answer to a similiar question at CodeProject's forums reveals a hint. Abstract:
[...] Looks like you are working on a web application that is actually a
Website as per Visual Studio. You would need to create a new Web Application
and probably copy over the source files there. [...]
http://www.codeproject.com/Questions/173637/Setting-Build-Action-for-Files-in-App_Data
Have you tried this:
You say you haven't got the option being suggested by other posters.
If this is the case, than it is quite possible that your Visual Studio settings are corrupt; this can give rise to all sorts of odd behaviour.
I would suggest you reset your settings, but please be aware you will lose any custom IDE settings that you've previously applied.
Try this:
In Visual Studio, go to Tools->Import and Export Settings
Choose "Reset All Settings" and click Next
Choose to save your current settings if you wish, or select "no" and then click next.
Choose the collection of settings( he IDE preset) you want, probably "Visual C# Development Settings"
Visual Studio will now revert all settings. Hopefully this will make the Build Action reappear.
[EDIT]
It might be worth trying safe mode too.
To do this, start up a "Visual Studio Command Prompt" from your start menu/programs list in Windows, and start Visual Studio with
devenv.exe /SafeMode
Does this make the options appear?
You can copy the file from Windows Explorer and paste it in the Solution Explorer. It will replace (or do nothing but incorporating it in the proj file) the file and recognize it as C#.
Normally you should see a Property named "Build Action" in the first line of the Property Window. This property should be set to "Compile".
Please select file and right click on it so that you will get following screen
Than click on the Properties you will get following screen
You can find build option in as a first option.
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!