Short version
VS2013, switching property page views of files to a certain configuration shows the wrong configuration!
Long version
I have a solution with several projects, each project containing a "Debug", "DebugRelease", and "Release" configuration.
For the projects, viewing the properties in the property page viewer (right click, choose "Properties") displays the configuration settings corectly.
For individual files, viewing the properties in the property page viewer looks correct in Release, looks correct in DebugRelease, and Debug seems to display the same properties as DebugRelease.
In fact, making any changes and saving them causes the project XML to make changes for "DebugRelease". Additionally, making changes in "Debug" causes "DebugRelease" to change as well... Seems like "Debug" for some reason isn't being displayed.
Compiling seems to compile to DebugRelease as well, even though the solution configuration is set to use Debug across all projects.
If I rename the "Debug" configuration to something that's not a prefix of "DebugRelease" it seems to work okay. If I rename it to a prefix, however, the same problem persists.
More vexing still, I have other project configuration names that are similar (BlahBlah_Debug, BlahBlah_DebugRelease, and BlahBlah_Release) and only some of those display similar behavior -- some of them work fine.
Problem first noticed under VS2013.4. Updated to VS2013.5 and it still persists. This didn't used to be an issue.
The obvious work around is to rename the project configurations, but there's a decent amount of tooling that expects the configurations as they already are.
Related
My android app builds and runs just fine on debug, but when I switch it to publish and deploy the app manually, things start breaking. Images are missing, entry fields don't work (placeholder text shows up, and the keyboard pops when I click on the field, but nothing I type in shows up), and some of my tap handlers aren't working. Are there any suggestions on what would possibly cause this? Seems odd that just changing to publish would cause that...
Try to change your Release linker settings to Don't Link/None and see if the same behavior of the Debug deploy comes back. If so, you have a problem with the linker stripping things it shouldn't.
developer.xamarin.com/guides/android/advanced_topics/linking
This will of course increase the size of the package dramatically and you'll want to play around with the different preservation methods.
https://developer.xamarin.com/guides/android/advanced_topics/linking/#Preserving_Code
https://developer.xamarin.com/guides/android/advanced_topics/linking/#falseflag
https://developer.xamarin.com/guides/android/advanced_topics/linking/#linkskip
I would highly recommend attempting to linkskip any third party assemblies in full before going into complete investigation mode. You can then use a Custom Linker configuration file to define exactly what you should not eliminate via the linker:
https://developer.xamarin.com/guides/cross-platform/advanced/custom_linking/
I downloaded an ASP.NET open source solution and opened it in Visual Studio 2010. VS is running as admin.
Everytime I switch the solution or a project from Active (Release) to Debug and uncheck 'Optimize code' and save, these changes don't stick. The solution or project reverts back to Active (Release).
Why is this happening?
You also have to change it in Configuration-Manager (see pictures).
I just had this exact issue. The solution ended up being:
Go to Tools ⇒ Options ⇒ Make sure "Show All Settings" in the lower left is checked.
Then, in that same window, go to Projects and Solutions ⇒ General ⇒ check "Show advanced build configurations".
I have no idea why this checkbox was suddenly unchecked for me this morning, but this worked.
This is guessing a little, but anyways:
Most likely, you are using build configurations that don't include your start up project for Debug build.
Look for the 'Manage Build Configurations' (I think, no Windows machine nearby) menu item. It will show you a list of projects with tickboxes on the right to show whether it is to be built in the build configuration.
Switch to 'Debug' in that dialog and make sure your startup project - or the project that your starting the build for - is actually included in the build.
PS It is even entirely possible that the 'misbehaving' project is actually lacking a Debug build (it might have a deviant name, like DebugConsole or something else entirely). In that case, use the Project menu to add a build configuration of the proper name for that single project. Afterwards, check (again) that said build configurations are checked in the 'solution wide' build configuration dialog.
HTH
Changing the properties of a configuration doesn't change the current build configuration. If you open project properties, change from Release to Debug and make some changes, after exiting the dialog, you will build on the same platform as before. To change the platform you're building on, there is a combo-box right above the code - use that. You should have all available configurations in the list. When you open the project preferences dialog, the current configuration will be the default one in the dialog.
I opened the csproj file in a text editor. Noticed there were two PropertyGroup sections which look like duplicates, one was Debug|AnyCPU and the second was Release|AnyCPU. I deleted the second one and the debug one showed up.
Luchian Grigore's answer explains correctly one simple misconception that could lead to this problem and aaaaaaa's answer gives another way of correcting it: there is a dialog that looks like you are selecting the configuration to build but you are actually just selecting the configuration to configure.
However neither of their ways of opening the 'Configuration Manager' actually worked for me -- I had to click on the button configuration manager at the top right of the solution Properties.
(Note that the place where you choose the configuration is called Configuration Manager, whereas the place where you manage the configurations is Properties.)
.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.
I added Parent Settings File to the solutions folder. After that I unchecked there rule SA1101 in the parent file. Also I set "Do not merge with any file" in parent file, and set merge in the parent file in the project`s settings file.
But after I build project I get this error. I attached window with error and settings winwows - there are no overloads or something like this.
I really don`t now what I can do, to resolve this issue....
ADDED.
But in resharper all rules work normal. But when I try to build solutions - my settings are ignored.
I used StyleCop Version 4.5.24.0
The problem is in Style Cope For Resharper. I tested the same solutions on another PC and all works fine
I have a web project running in Visual Studio 2010 and target .Net framework 4. When I 'Build' the solution it will tell me the build was successful even though there are (known) errors in the code. If I open a page that has an error, the compiler will then pick up on the error and underline it in blue instead of red.
Is there a setting that would drive this kind of behavior? Any ideas on how to fix?
If you have multiple projects in your solution it is possible that one of them is not set to build. In your build output window did you see the name of the web project you are having issues with?
Also, check the build configuration manager to make sure you have it set.
If it's an MVC app, the view files (*.as{p,c}x) will not be compiled unless you explicitly enable it by passing /p:MvcBuildViews=true or enabling that flag in the project file for a given configuration.
I'm having similar (if not identical) problems with compiling an ASP.net 4.0 WebForm. I have a page that is a copy of an existing page in terms of markup, but the code-behind has not been created. As an example, the markup has an ASP:Button with a click event, but the event handler has not been declared in the codebehind yet. When I do a full Build/Rebuild/Clean etc., no errors are found. I open the page, and a compiler error is thrown. As far as I know I haven't made any changes to settings anywhere, just started doing this recently. Additionally, it appears that my break points aren't being caught anymore either. I'm not sure if the two are related, but they did start happening around the same time.