I have a Visual Studio 2008 project where some code files are generated with each build (a parser, integrated via MSBuild aka editing the *.csproj file).
VS does not know about the generated nature of these files (i.e. they are not the result of a "Custom Tool). So they "change" with every build, naturally. And VS2008 asks me after every build if I would like to reload those files:
This file has been modified outside the source
Do you want to reload it?
That would be ok if I had one of those files opened and in front of me, but I get these modal dialogs even with none of the code files opened.
So my question is: Is there a way to disable this dialog, per project, per solution or globally?
Thanks!
For VS2008: Tools > Options > Documents > Detect when a file is changed outside the environment
For VS2010/2012/2013/2015: Tools > Options > Environment > Documents > Detect when a file is changed outside the environment
In Visual Studio Pro 2012
There is an "Auto-Load changes, if saved" that works.
Tools > Options > Environment > Documents > Detect when a file is changed > Auto-Load changes, if saved
Because a picture paints a thousand words...
I generate source files on every build, and I don't (normally) get a "file has been modified" message if the file is not open in the editor.
I was getting it just now, however, on a closed file. (That's why I went searching for this question.)
I think that's a bug. The file seems to get wedged sometimes. (But this is the first time it has happened in about a year.)
I think I've found a work-around just now: Open the offending file and then close it again.
The point is, you shouldn't need to turn off changed file detection.
This is an old post, but what worked for me was slightly different and I wanted to share:
This file has been modified outside the source
Go to Tools -> Options -> Debugging -> General and uncheck "Require source files to exactly match the original version". This allows you to use source code which is not the same as original version.
Related
I get this error message in a Reporting Services solution in Visual Studio 2010 [we're using TFS for source control]:
There appears to be a discrepancy between the solution's source
control information about some project(s) and the information in the
project file(s).
To resolve this discrepancy it will be necessary to check out the
project file(s) and update them. If the check out fails, however, and
the solution is closed without saving, you will see this warning again
the next time you open the solution.
Only some projects get checked out but others seem OK. So here is what I tried:
I tried to compare what might be different between the project
files that work and don't work but nothing catches my eye.
I looked around and tried a
number of proposed solutions like "adding a file, checking in and then removing
it and checking in". No luck.
I tried to look for "Scc" tags in project files
but I don't see any in there. I also don't see them in projects that
work fine. Looking at my solution the Scc entries look reasonable.
Help!! What am I missing?
Using Visual Studio you can solve this problem by unbinding and binding the solution and/or projects. Try this:
Open the problem solution in VS (did this in VS2013 just now)
Undo all pending changes to all the projects in that solution and the solution itself
Go to File -> Source Control -> Advanced -> Change Source Control
Select the problem projects and click "Unbind"
Click OK and close the window (THIS IS IMPORTANT - if you don't click OK VS doesn't update the solution properly)
Go to File -> Source Control -> Advanced -> Change Source Control
Select all the projects you unbound in #4 and click "Bind"
Click OK and close the window
Check In Your Changes
Close the solution and open it back up and everything should be fine now
Experienced the same problem in VS2015.
I found this workaround worked for me:
Change < Scc* > tag values to "SAK" (Should already know) in the project files:
<SccProjectName>SAK</SccProjectName>
<SccProvider>SAK</SccProvider>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
https://connect.microsoft.com/VisualStudio/feedback/details/616751/discrepancy-between-the-solutions-source-control-information-about-some-project-s-and-the-information-in-the-project-file-s
Workaround #3
There was 1 person on our team who was doing the conversion to TFS from VSS who didn't have any errors. He never checked in his solution so we never saw it until now. I looked through his solution file and there are differences. I found the following differences for each project in "GlobalSection(TeamFoundationVersionControl) = preSolution":
Our NETReports.sln in TFS (the file that gave the error above):
SccProjectUniqueName7 = EllinReports\\DiagnosticReports\\DiagnosticReports.rptproj
SccProjectName7 = EllinReports/DiagnosticReports
SccLocalPath7 = EllinReports\\DiagnosticReports
His NETReports.sln (the file that DOESN'T give the error above):
SccProjectUniqueName7 = Reports\\DiagnosticReports\\DiagnosticReports.rptproj
SccProjectTopLevelParentUniqueName7 = NETReports.sln
SccProjectName7 = Reports/DiagnosticReports
SccAuxPath7 = http://<server>:8081/tfs/dev
SccLocalPath7 = Reports\\DiagnosticReports
SccProvider7 = {4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}
I guess it all makes sense now. We were all missing the SccAuxPathXXX, SccProviderXXX and SccProjectTopLevelParentUniqueNameXXX. Having them made the difference.
.NET 4, console application. The project is set to 'Debug' mode. The breakpoint being set is in the primary/startup project. I have right-clicked -> Clean, and right-clicked -> rebuild, both on the Solution and project levels.
Following the instructions in this SO question, I have confirmed that my "Build and Run" options are set to 'prompt' for both 'When projects are out of date' and 'when build or deployment errors occur', and I am NOT getting a prompt when I F5 to build/run.
Also, the 'save all changes' under 'before building' is also selected (plus I manually saved them myself).
I monitored the output window of the application, see this line:
'MyApplication.exe': (Managed (v4.0.30319)): Loaded 'C:\exepath' Symbols Loaded.
I restarted the VS2010 instance. I restarted all open VS2010 instances (of other projects). I've even gone through a reboot.
However, the breakpoint I am setting in the startup project is a hollow-red circle, with the notice that 'This breakpoint will not currently be hit, The source code is different from the original', and, in fact, is never hit.
So, this is really 2 questions:
1) How do I fix this problem so I can properly breakpoint
2) When I see this, does that mean my code is executing from an older build?
I've had this problem once myself but that was on a vsto addin. In that case there were left over intermediate files under the users/appdata directories that were actually loaded instead of my app.
There is this blog article that has a whole load of possible reasons for this error and then a whole bunch more in the comments from other users
This can also happen if you have a solution with multiple projects, and have the wrong project selected as your startup project in VS2010 and VS2012.
Now, obviously, I wouldn't expect debugging to work if I have the wrong startup project selected -- the debugger is attaching itself to the wrong process!
But this error message (in my case) was terribly misleading. It made me think something else was wrong. I tried a bunch of solutions in this thread (nuking various /bin and output directories) when really it was something very simple (wrong startup process).
If you are using vb, check that you are building the project for the active solution configuration (Build, Configuration Manager..., Column under Build is checked. Also check the project properties, Compile tab, Advanced Compile Options, and Generate debug info is set to Full. Sorry I can't tell you where this may be in C#.
The only other time I've seen this is when two projects in the solution are referencing the same dll but they are referencing from different sources. One from a project reference and another from a file reference for example. If the "copy local" option is true, there would be the potential of overwriting the dll with an older version of the same dll.
My solution might help people who have signed the assembly.
After lot of head scratching for the past two days, I was able to resolve the same issue by doing the following simple steps:
Go to your Visual Studio project properties.
Go to the "Signing" tab.
Uncheck "Delay sign only" option if it is checked.
Now run your project and it should work.For me it did work.
In my case was this same problem (“The breakpoint will not currently be hit. The source code is different from the original version.”) caused by fact, that I tried add breakpoint to declaration:
DateTime dt;
bool b = DateTime.TryParse(null, out dt);
(first line of code)
So I assume that message is "universal" and may have many different causes.
This can happen if your system clock was changed since the last compile. Your PDB file will be different date than the one your are trying to debug. Delete the PDB files in the project and recompile.
I experienced the problem when Project > Properties > Web did not have "Enable Edit and Continue" selected. After enabling this feature the issue was corrected.
It is important to note that under Tools > Options > Debugging > Edit and Continue "Enable Edit and Continue" was selected, but it was not enabled for this project.
Just go to Tools / Import and Export Settings
Choose reset all settings then click Next
No, just resetl settings, ovewriting my current settings then click next
Choose your current language, por example C#. then click Finish
If you have multiple solutions open, try simply closing all Visual Studio instances and restarting only the instance you need.
In my experience this has happened when two branches of nearly identical code are open in different instances.
doing a "clean solution" from VS Build Menu might help you.
I had to go over all those steps to fix the issue on my computer.
Make sure that debug = "true" on your web.config
Clean and rebuild all projects
Delete every file inside the bin folder of all projects
Close and open Visual Studio, rebuild, and run the project again.
Go to your solution folder -> obj -> Debug - > delete the .dll file and build the solution again.
Sometimes, in debugging mode, I try to watch code at some level of the call stack, and I get an error:
There is no source code available for the current location.
I know what it means. If I know where the file is, how can I give the source file to Visual Studio?
The first time, it gives me a browse window for search, but at this time I didn't have the code. When I downloaded it from SVN and tried (after restart of the whole computer) to access the code again, I get the error.
Please don't explain me that Visual Studio can't find the file and because of it gives disassembly, I know it. I searched for the option to give it the file.
In Visual Studio (at least since v.2005) you have to check the Solution properties:
In the Solution Explorer, right-click on the Solution -> Properties -> Common Properties -> Debug Source Files.
There is a list here: "Do not look for these source files:" - remove (all) entries from this list, then VS should ask you for the source path again.
Here's a screenshot from VS 2013 Express:
None of the above steps worked correctly in VS 2013 for me.
After removing the incorrect source path from the Solution -> Properties -> Common Properties -> Debug Source Files list, closing all instances of Visual Studio, each time I ran and stepped into the code, I would see a file dialog would pop up and go away and then VS would step to the incorrect source location again.
After numerous attempts at this, I used a hex editor to do a Unicode string search and found the offending path was still in my solution's .suo file. Deleting that file still did not fix the problem.
Finally, I opened the solution again, went to the Solution -> Properties -> Common Properties -> Debug Source Files list and changed the incorrect source location to the correct one (i.e. instead of deleting it). I then Ctrl+Shift+S to save all, exited VS, started VS again and started a debug session. This time it stepped to the correct code.
So, if the above is not working for you, there's an issue in VS 2013 with it caching the path that prevents deletion from working and you must change the existing path.
If I remember correctly, if you fail at the task of locating source code when it first occurs, the modules are added to the excluded modules list.
Go to Tools -> Options -> Debugging -> Symbols. Under "All Modules, unless Excluded", there's a link button "Specify Excluded Modules". Open that dialog, and I think you'll find your modules in there.
Is anyone aware of a way to make visual studio completely ignore a file when compiling? I have a C# solution that has a foo.config file that isn't really a standard config file - it's just a text file. During compiling VS grabs a hold of the file and bombs.
I'd like for it to act as though it's just a text file. I do not have the option of changing the name of the file.
EDIT: Please note that BuildAction does not exclude files from the compiler checking them. It simply decides if the file is compiled into the assembly, whether it's content (like a jpg or something), or whether it is a resource file. For more info: see the MSDN page.
EDIT2: Apparently, if you have a text file that is named foo.config and you have it open while building, VS2005 will pop up an error thinking that the file should be xml. However, if you close the file, VS2005 will ignore it.
Solution: Visual Studio validation causes errors if you have a non-compliant file open during build time. For an example of how to turn this off (for HTML), see Scott Guthrie's post. As Allen mentioned, you should also have the Build Action turned to "None". Unfortunately, this will not stop build errors if you have the file open.
right click > properties
Build Action: set to "None"
Edit: If you're talking about app.config, you really cant mess with the format of that, you need to put it in a different .config file.
I just double checked, VS.net doesnt care as long as its not app.config or web.config and the config file build action is set to "None", it will "error" if you have the file open but it will not cause the build to fail or keep it from building the assemblies.
Close the file and the errors will go away, similar to the errors you get about HTML markup. The displaying of these "errors" is probably a configurable setting in vs.net
The action to take depends on the solution and and file type. For instance (in VS2005), in a C++ solution I can right click on the source file name in the solution explorer and view its properties. The first "General" option is "Excluded From Build", which will allow you to exclude the file from the build process without having it excluded from the project altogether.
I pulled up a .config file in a C# solution, and found a "Build Action" option under the Advanced section. That should probably be set to "None".
Just right click on the file and choose "Exclude from project".
If you still want to see it in your project, select the project and click the "Show all files" button at the top of the solution explorer. This will show all the files in the directory tree even if they aren't actually part of the project.
Are you sure that VS compiling .config file???
You should check it's Build Action in file options and may be set it to none.
Is it possible to open a project in Visual Studio 2008 without opening all the files that were previously opened last time I had the project open. I have a habit of keeping many files open as I am working on them, so next time I open the project, it (very slowly) loads up a bunch of files into the editor that I may not even need open. I have searched through the settings and cannot find anything to stop this behavior.
Simply delete the .suo file.
It contains the list of open files.
A bit of research turns up the fact that you can do it with a macro:
Create a new macro (or use an existing one). You should see a module called EnvironmentEvents in Macro Explorer. (For details, see here.)
Open the EnvironmentEvents module.
Put in this code:
Public Sub CloseDocsOnExit() Handles SolutionEvents.BeforeClosing
DTE.ExecuteCommand("Window.CloseAllDocuments")
End Sub
Save and Build the macro.
Open a whole bunch of documents in your solution, then close Visual Studio.
Yay! No more open documents!
(Note: Despite that it says SolutionEvents, it also works if you're working on a project that doesn't have a solution.)
I never realized how much that annoyed me as well! I haven't been able to find a setting, but in Options > Environment > Keyboard you can bind a shortcut to Window.CloseAllDocuments. ALT+X was unbound for me so I just used that. I'm interested if there's some hidden setting to automatically do this on solution exit though (or load).
Edit: Totally read the question wrong at first - ignore my first (now gone) answer. :)
I changed the keyboard mapping for CTRL-SHIFT-C from bringing up the Class View to closing all document windows - something I use several orders of magnitude more often - and then I just clear my workspace before closing a solution.
Try the following:
Close the program after closing all files.
Make a copy of [whatever].suo
Open the solution again, open some files, and exit.
Copy (don't move) the old .suo file over the one that was just generated.
Make the .suo file read only.
If you have a repository you might want to check that file in.
I suggest this because I was having the reverse problem, where it wasn't opening my old files automatically, and the cause was a .suo file that had been checked into the repository and was (for some reason) not being overwritten by Studio. The file wasn't even write protected.
I was hoping for something a little more automatic. VS will create a new .suo file every time the project is saved. So I would have to delete that file every time I open the project. I also don't want to have to remember to close all the files before closing VS.
Other IDEs that I have used have similar functionality, but also make it rather simple to turn on/off.
Thanks for your help.
Or you can close all open document from the Window menu before closing VS.
In Visual Studio 6.0 (VC++), the procedure is slightly different.
Delete the .ncb file (located normally in the same place as your .dsp or .dsw files).
The only way works for me is : change the project location and again reopen the solutions form there. :)