I'm having a weird problem in Visual Studio 2008. Every once in a while, after adding/removing some members of a class, when examining the contents of an object of that class in the watch window the changes to that class don't appear to have been recognized. Instead, all of the old members are there, including anything that was removed, and nothing new shows up. Furthermore, the data of the members it shows is messed up, likely because the memory layout of the object has changed.
I've been using Visual Studio 2008 for years and encountered this problem for the first time about a month ago. Re-installing the program did the trick, but now it's cropped up again.
I've tried a full rebuild, deleting the .pdb file, deleting the .ncb file, deleting the .exe, the .obj files, the .sln file, etc. Nothing seems to solve it. Has anyone come across something like this before?
Thanks!
UPDATE
I realized it may not have been obvious from the initial post, so I wanted to clarify that the code behaves correctly, it's just the debugging information that's wrong.
UPDATE Number 2
Just tried downloading Visual Studio 2008 Express Edition, but it has the same problem.
So finally I was able to fix this just to moving around some variables in the header file. I'm quite sure I tried this the last time I encountered this problem, but to no avail then. This time, for whatever reason, it seemed to work. Thanks Joachim for your time in trying to help!
Related
This is driving me crazy. I'm using VS Code as my IDE for Go development. About every third or so time I save my changes, it corrupts the file by removing random characters. I have tried manually removing all extensions, uninstalled VS Code, re-installed VS Code, and installed only the Go extension, but it still keeps happening. Based on what's happening, I guess I can isolate it to the Go extension, but I'm not seeing any other posts associated with the behavior. Is anyone else experiencing this and, if so, what have you tried?
This VSCode bug addresses the issue.
Recently, whenever I change something in my code, rebuild, and attempt to debug, I get the error "This breakpoint will not currently be hit, No symbols have been loaded for this document."
But then as soon as I restart my computer, everything is fine and I can debug properly. Why is this happening? It's really frustrating having to restart my desktop every time I try to debug my code. I've looked all over stack overflow and MSDN and can't find any solution to my particular problem. Any help is appreciated
"This breakpoint will not currently be hit, No symbols have been loaded
for this document."
(As for this error message, it's common error which has different causes. I can't give the most direct correct answer for this issue, I can only give you some tips for trouble-shooting. In order to avoid losing contact in the round-trip comments, I post those content as answer instead of comments.)
Since VS2015 have been released for long time, I would think this issue is a particular one, not found similar issues online.
First of all, please create a new simple project to check if this issue occurs in new project when debugging.
If it persists in new project, I think this issue has something to do outside environment like VS settings, VS config files or Debug options.
You can try:
1.Go Tools=>Import and Export Settings=>Reset all settings =>No,just reset settings=>Finish
2.Repair VS IDE since it seems to work well in the past, and just got the issue recently, so maybe something is broken for your IDE(In Control Panel find VS2015, right-click=>change=>repair). Also, make sure you have the latest VS2015 Update3 instead of earlier versions.
And if it works well in new project, then maybe the issue is about the whole project or solution itself. You can try:
1.Navigate to solution folder, close all vs instance, delete the .vs, bin and obj folders and restart VS to check if it helps.
2.Make sure you've loaded the required symbols, check the content in your Modules window during debugging, there's possibility you don't load necessary symbols successfully.
3.Check the output folder after your rebuild, check in folder like bin\debug folder if you have both the .exe and .pdb files. And make sure the .exe and .pdb files are up-to-date after your rebuild by checking their Date Modified.
Hope it helps and more info about the project type, dependencies would be better:)
I'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
I have just moved an Asp.Net MVC project into our main solution, straight away the performance in cshtml files is incredibly slow, you can see each character appear after a 1 second delay. Also switching between .cs files also takes 1 second.
Outside of this solution performance is fine, this solution holds a number of projects which my solution references.
The problem occurs on 2 machines which have Update 2 present, a machine that doesn't have Update 2 present doesn't get the problem
Neither my machine nor the others use any plugins
Obviously I have a workaround, just do my coding outside of the main solution but has anyone else experienced this?
thanks
I have had similar issue with performance of some files and found it to be Plugin related. For my setup the issue was Web Essentials 2013 needed to updated.
If that doesn't work, try disabling all of your plugins, especially and large ones like Resharper (and Resharper plugins!), restart VS and see if the problems are resolved. Then renable plugins until you have found the culprit.
I can make it freeze simply by putting a debugger keyword in a ts file, as soon as it hits it it freezes VS for a good minute, there are other problems all seemingly related to .ts files.
I went up to RC3, no change. Uninstalled and went back to VS2013 without any updates and it now works fine
NB RC3 did -not- help it at all
Just to be clear, I have never installed Web Essentials and this is now VS2013 with "microsoft.com/en-gb/download/details.aspx?id=34790"; installed
Question says it all. I'm trying to write a Visual Studio addin (2012), and the experimental instance always launches without running anything in the addin. No breakpoints are hit in the main instance, nor does the addin get loaded by the experimental instance.
I should point out: it worked at one point once or twice, then I deleted the project since I thought it was the wrong kind of project, but ended up recreating it with the same name.
No amount of fiddling with "allowing addins to load" or resetting the experimental instance or cleaning the registry manually fixes the problem. I also tried looking for my addin dll, but it wasn't in the list. I'm totally out of ideas and possible search terms. Any suggestions?
I had the same problem as you and have just discovered the fix for me, it relates to the new "file properties" entry in the add-in project that gets supplied.
If you open this file which is in my case called "[App Name] - For Testing.AddIn" you'll see XML markup containing things like the AddIn friendly name, description e.t.c.
For me I found that I'd immediately renamed the output assembly for my project and this no longer matched that found inside this properties file:
<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>11.0</Version>
</HostApplication>
<Addin>
<FriendlyName>My Addin</FriendlyName>
<Description>My Addin description.</Description>
**<Assembly>E:\Workspaces\Scratch\MyApp\bin\MyApp.VisualStudio.Addin.dll</Assembly>
<FullClassName>MyApp.VisualStudio.Addin.Connect</FullClassName>**
<LoadBehavior>1</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
I checked the name of the assembly and class names fixed them up, saved the file and hit debug and it all started working again! Hope this helps...
I had a similar problem... fought with it for quite a while, and eventually, absolutely randomly experimented with adding other configurations to the project (Configuration Manager) and also changing the framework.
One of the two magically helped. (I think it may have been the framework... though it makes no sense).
I am not saying that the same thing will work for you.
The random experiment was not really random: I got hold of a "debuggable" add-in off the web, and compared every single item in the project, solution and all other files, to find what could be different. This is my true suggestion.
If all else fails, you can also try to manually attach the debugger, see if you can make headway this way. [ that did not work for me, but it may provide valuable information, and... not all bugs are created the same. ]
Seems like there are different solutions to this problem but this finally helped me:
Changing <LoadBehavior>1</LoadBehavior> to <LoadBehavior>0</LoadBehavior> in the AddIn-file and put it manually in C:\Users[UserName]\Documents\Visual Studio 2012\Addins
Restarting Visual Studio (I use 2012)
Complete AddIn-file:
<?xml version="1.0" encoding="UTF-16" standalone="no"?>
<Extensibility xmlns="http://schemas.microsoft.com/AutomationExtensibility">
<HostApplication>
<Name>Microsoft Visual Studio</Name>
<Version>11.0</Version>
</HostApplication>
<Addin>
<FriendlyName>[Friendly Assembly Name]</FriendlyName>
<Description>[Description of the Addin]</Description>
<AboutBoxDetails>[About details]</AboutBoxDetails>
<Assembly>[Full path to the binary e.g. C:\Test\debug\test.dll]</Assembly>
<FullClassName>Test.Connect</FullClassName>
<LoadBehavior>0</LoadBehavior>
<CommandPreload>1</CommandPreload>
<CommandLineSafe>0</CommandLineSafe>
</Addin>
</Extensibility>
In my case I moved to a different developer machine where it was previously working on the old machine, but on the new machine I didn´t have any '[Assembly Name] - For Testing.AddIn' since I didn´t bother to check it in. I think the LoadBehavior is the difference between For Testing and the regular AddIn.
I had the same problem. Debugging worked until I closed all instances of Visual Studio. I then opened Visual Studio again and it said that the add-in that I had been debugging had stopped working. When Visual Studio asked whether to remove it, I said yes.
Apparently removing the add-in in this ray renames the "[AppName] - For Testing.AddIn" file to have an underscore appended.
To fix the problem, go into the add-in solution and look at the properties on the "[AppName] - For Testing.AddIn" file. Go to the folder where the file is located. Rename this file in the file system to match the name of the file in Visual Studio.
In my case, Resharper was the reason. Everything gets back to normal after disabling Resharper.