Debugging in visual studio seems to have been broken with sp1.
Single stepping randomly does not work and just starts to run. Sometimes breakpoints are ignored. It is unpredictable and unusable. It will generally hit the first break point but after that it is totally unpredictable.
Any idea what needs to be done to correct this behavior ?
Make sure you are debuging using the debug configuration, not the release one. Also make sure optimizations are disabled in debug configuration.
Optimizations must be off when you debug else it can lead to very erratic behaviours like these.
For C# projects, which I am assuming the question is about looking at the tags, the optimization option would be located in the "Build" tab of "Project > Properties..." Last option of "General" it's called "Optimize Code".
There is a fix which for some reason isn't included in the update process:
http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796
It worked for me although some people say they still have the same problem.
We are using c# as a language.
The problem has been identified by microsoft.
quote from forums:
We have identified the root cause of this issue and are currently working on a solution. We apologize for the inconvenience that this is causing you. We will let you know as soon as we have a solution. In the mean time, if we discover any workrounds, we will post them here.
Related
Ok, I'm experiencing a truly random bug and I cannot find any reason why this would happen. I have an application that I update that was first developed MANY years ago. I work on a sizable dev team whose sole responsibility is to manage this application and we've come to accept that the project is a bit of a "franken-code" project. We are but humble developers in a line of many generations of developers who've inherited this project. (This will be important to know later.)
There is a portion of our application that deep within the initialization process calls the following code:
string strPath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().CodeBase);
string strFile = strPath.Substring(6) + "\\" + FILE_NAME;
Here's the deal. My fellow team members, and myself, have been able to modify and build higher-level, UI and DB related sections of our solution for an eternity. I, nor anyone else, has modified the above code, or any code in the same code file (or project within the solution, for that matter.)
However, today while working in a completely different section of my application I began to get some really odd "Out of Memory" exception errors. I'm not sure if that relates to my problem but I felt it was worth mentioning that after rebooting my machine and reloading the VS solution, I'm now consistently getting the following exception when I attempt to run a debugger test, when the initialization process attempts to execute the above mentioned snippet of code:
Exception: A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
Message: URI formats are not supported.
I've googled this error message and it looks like the original dev was simply doing this wrong. This seems to be a common error, but what baffles me is that this has never been a problem until, randomly, today.
I know this is an odd question, but is there a way to fix this without modifying this code. As I mentioned, this is a really complex application that often feels a bit cobbled together. Our team is attempting to clean up, or replace, much of the applications functionality but there are portions we simply do not touch because we have no solid clue how the application will work once it is deployed to our production environment. This is a highly-critical application and it cannot be broken.
Might anyone have any clue what may cause this to "magically" start happening? Especially since I have been working in UI-related code, and no where near the low-level, configuration resolution section of code where this came from.
ADDITIONAL NOTES
We use source control. If I download, build an run an older revision of the application, it works.
We use AnkhSVN and when I inspect my changed files, again, there is nothing that has been changed that relates to the code that is now failing.
No one else in my team has ever seen this.
To my knowledge, I've not tweaked any setting associated with my project. I've taken a look at my project properties and everything looks normal. I guess there is a chance that I've hit some odd key-combo and enabled/disabled something through shortcut-keys, but I have no clue what that might be.
Any help is appreciated. Sorry for the novel. I'm just stumped and I'd rather not use a different method for acquiring this path string if there is ANY chance that altering this process could behave differently in different user environments.
I can only assume some working file within the Visual Studio that is associated with the project/solution had become corrupt. I searched through the text of my project files, and all of my code, and I didn't see anything out of place.
As I mentioned, we use source control. To attempt a fix, I pulled down the same source revision that I initially pulled for my current task. I compiled and ran the application. Everything worked properly in its "vanilla" state.
Next, I copied in all of the files I knew I had modified. I hadn't added any new project references or resources, so I just copied over the modified .cs files. I built and ran the application and I've had no trouble since the pull from my branch.
This does not answer the question of why this occurred, but this method can provide a solution to the problem.
I can confirm this change in Path.GetDirectoryName occured to me after installing VS 2015 and rebuilding our project in it so it seams to be .NET 4.6 feature.
Rebuilding the project again in VS 2013 returns the previous behaviour where Assembly.CodeBase with "file:" prefix is acceptable by Path.GetDirectoryName without any exception.
But rereading the MSDN documentation, there is a statement that "file:" paths are not supported, but this is not mentioned in ArgumentException thrown in VS 2015 code.
First of all, find out how many versions ago this started occuring: start with the current version, and work back changeset by changeset until it no longer fails.
It sounds like, for whatever reason, System.Reflection.Assembly.GetExecutingAssembly().CodeBase now returns a string that GetDirectoryName doesn't like. So, check the project files, the .sln, the repo config, anything that could cause a file to be in a different location.
If you can't find anything there, check the other files from that same commit, even if they appear that they shouldn't be related.
First Chance Exceptions generally happen when you've got multiple threads happening, so check for new threads that weren't in the previous version. I've also had situations where First Chance exceptions would only get caught under certain situations, and are silently ignored otherwise, so look changes in Debug settings: it's possible that this problem has always existed, you just haven't had the right settings to catch it until now.
Remember that under a source control, other people can change things that are "yours", even if only by accident.
I have Resharper 9 installed and StyleCop as I'm trialling then to see if my work should get the tools installed for all developers (So I'm very new to using both tools).
StyleCop has a number of rules that affect line formatting, such as: SA1116. Resharper then picks up when these rules are violated and it offers the option to have it automatically fixed (as you can see below).
The only problem is when I actually hit enter nothing happens. Well nothing happens 80% of the time for this rule violation as well as for a bunch of the other formatting issues such as a space between a cast and a variable (e.g. (double) myDouble;)
It seems so erratic, does anybody know how to improve this or is it simply credit to StyleCop not completely integrating with Resharper? (In which case should I stop looking at recharper/stylecop combo as a "press button to fix" tool and more like "here's a warning, your welcome. Now if there's a button, press it you're lucky")
Cheers,
It might be worth raising this as an issue with the StyleCop project on CodePlex. However, the CodePlex project seems to be a bit abandoned - the current ReSharper 9 plugin is provided by a community member. There's a GitHub repo (although it doesn't have source) that you could use to try and file an issue.
There is an old video of Notch debugging and testing his code and while doing so he simply pauses his game, makes his code modifications, and resume his game with the new changes.
I found this old post explaining how he does it, but I'm wondering if there is an equivalent to Visual Studio 2012.
I know that you can enable Edit and Continue but this is a lot more restricted in the sense that you can't edit anything you want and you need to set a breakpoint. So Edit and Continue is not quite what I'm looking for.
I know that you can enable Edit and Continue but this is a lot more restricted in the sense that you can't edit anything you want …
Yes, there are some things that you can't edit with Edit and Continue. But that's the best you can do with the current tools, I don't think there is a way around that.
… and you need to set a breakpoint
No, you don't. You can use the “pause” button in VS (real name Break All), edit your code and then let it continue executing.
.NET's edit and continue is nowhere near as good as that provided by Visual C++, Visual Basic or any dynamic (ie script) languages which is a pity.
If you can live with the limitations (having to break execution, no 64-bit support unless you are v4.5.1+, no lambda/linq changes, changing active statements, and a few others) then you should be ok to do pretty much the same. I find though, that I always end up wanting to change something that's unsupported :(
The big alternative is to use unit tests - in that, if you have enough tests you do not need to go debugging into your code at all. I think its debatable whether you save more time or not, and maybe it depends on the programmer style which suits you better.
During my trial of ReSharper 5, I noticed its version of IntelliSense falls behind Visual Studio 2010's in three ways that were key to me:
ReSharper doesn't support IntelliSense in the "QuickWatch..." debugger utility.
ReSharper's IntelliSense seems to break down for me in .aspx files between the <%= %> tags.
I couldn't find a way to get a listing of properties within an object initializer block. (VS does this if you hit the space key.)
Thankfully ReSharper lets you use Visual Studio IntelliSense alongside its other great features. Am I missing out on anything great by not using ReSharper's IntelliSense?
Well you're losing quite a bit. Here are some quick facts about ReSharper code completion: http://www.jetbrains.com/resharper/webhelp/Coding_Assistance__Code_Completion.html
Smart Completion (Ctrl+Shift+Space in IntelliJ IDEA keymap) is especially useful because in common scenarios it gives you a narrow selection of symbols that you most likely want to complete, and in some cases acts as a shortcut to code generation features
By the way, Smart Completion is the kind of completion that you should use with object initializers: www.jetbrains.com/resharper/webhelp/Coding_Assistance__Code_Completion__Smart.html#object_initializers
As for completion within the <%= %> pair, this should work fine. Please let us know what exactly went wrong by submitting an issue to youtrack.jetbrains.net/issues/RSRP Thanks!
P.S. I work at JetBrains
A five minute comparison I'd say that ReSharper's gives you a bit of help in the typing.
So if you have a method that's A(int a, int b) and you hit ctrl+space when you select A it will add (), will place you in the middle of the brackets and will show you the information about the method. Other than that you're probably not missing much.
For me that is quite helpful, but if you're having trouble doing ASP.NET and those are known bugs / limitations its always best to pick the best tool for the job.
Personally I turn it off. It is annoying and slows me down. Here is a prime example:
No you're not missing much apart from a test runner that supports NUnit. I've had the same problem and also (rather worryingly), hideous performance. I tend to use the productivity power tools extension and the native refactor stuff instead. Info here:
http://visualstudiogallery.msdn.microsoft.com/en-us/d0d33361-18e2-46c0-8ff2-4adea1e34fef
R# also does stuff which I plainly do not want to do and my code ends up littered with commented resharper hints.
I find the CompleteCodeSmart functionality something I use frequently and save me alot of typing.
I'm making a refactoring tool that automates a few of the more trivial code styling things dealing with StyleCop. One of the things I'd like my add-in to be able to do (as an optional feature the developer can turn on/off) is automatically call the "Organize Usings -> Remove and Sort" functionality. This is a simple macro call.
However, my problem is that as I go through and recursively call the macro on every .cs non-designer file in the solution this particular macro checks for errors before execution. If there's a syntax error and my add-in starts calling that functionality, it throws up a dialog for each and every file.
What I'd like to do, is use the same method that function uses for checking for errors on the fly and then if there's an error that would cause the dialog to pop up, simply pop up a one-time notification and skip the calls on each file.
I know my add-in could check the error list, however I've found many times that errors that trigger problems in "Remove and Sort" don't always appear in the list. I've had the list be empty, then I try "Remove and Sort" and it tells me there's build problems. I then build the solution and sure enough it fails and the errors are populated. The only solution I'm seeing is to use the same functionality as "Remove and Sort" to check beforehand.
Does anybody know how I can detect compiler errors before building in the same manner as "Remove and Sort Usings"?
I'm not exactly sure what kind of errors you are talking about, I'll assume they are the ones that the IntelliSense parser generates. Yes, that parser isn't very reliable. It is not meant to be a full-blown C# parser, it was optimized to do a very different kind of job: providing context-sensitive help even if the code is incomplete and cannot compile. There isn't anything you can do to make it more reliable, other than waiting for the next VS release perhaps.
But it strikes me that you might be trying to fix the wrong problem. The key issue is that your add-in appears to be removing using directives that should not be removed. A real fix is to improve your code analysis engine so it reliably detects true namespace dependencies. Trying to guess which ones matter from hoping that IntelliSense is going to complain is only going to frustrate your customer.
It seems hacky, but unless somebody can come up with a better solution I'm gonna use a check on the errors list because it's better than nothing.
Additionally I think I may experiment with putting a timer around the call to "Edit.RemoveAndSort" and if it takes over a certain amount of time, pop up a one-time dialog mentioning that it looks like RemoveAndSort is having problems and asking if the user wants to cancel, or at least not call remove and sort.