I am creating an extension in Visual Studio 2012 and keep having this error which is getting rather frustrating.
The way I have dealing with it recently is that I have to go into the add-in manager before I start the extension, un-check all boxes for the add-in, close out of Visual Studio, reopen Visual Studio, start the add-in debug, re-check the add-in in the add-in manager, then restart the debuging. As you can imagine this is rather time consuming and is annoying. It also only works about 70% of the time. It occurs also when I try to build or rebuild the project and no other Visual Studios are running. Is there any way I can prevent this from happening or is there a way to fix this error?
As you're discovering, you shouldn't install an extension from the bin folder while you work on it.
Remove the extension entirely from your main copy of VS, then create a separate test environment by running devenv /rootsuffix MyTest and install the extension there.
You should then debug the extension from that instance and kill it when you're done.
Related
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
I use unmanaged dll with P/Invoke in this app, and I always tested it inside Visual Studio (with debug mode on x86 CPU because the dlls are only x86), and it works just fine. But when I just start the exe manually after some time (probably at the first operation with those dlls, but I don't know exactly) it says the exe has stopped working, and it starts checking for solution (I use Visual Studio 2013 on Windows 8.1, if that matters). I tried to add the dlls to the project as existing item, but that doesn't help. Also I know, that it's not because it can't find those dlls, cause if I delete them, it doesn't crash, just freeze without any error message. Shouldn't it work the same from Visual Studio as manually started?
There is also a weird bug when I run from Visual Studio: everything's work fine, but sometimes Visual Studio just suddenly stops debugging, as if the program were closed and the GUI of my app freezes, and I can only close it by closing Visual Studio (as I close it, the GUI disappears). Maybe it's a totally different problem, but it can be connected.
Edit:
Here's the project on github, if somebody could check it:
https://github.com/geiszla/CycriptGUI
Some news: If I run it with Ctrl+F5 it also crashes. What's the difference between F5 and Ctrl+F5, that can cause this problem?
Searched all over Google with no real simple answers. Here it is folks(at least it worked for me and is simple):
When you run the console app in Visual Studio, look at the output window at the bottom, get the location of the ..\bin\Debug\*.exe
Copy the *.exe and the *.config to your desired folder, run it, it should work the same way in Visual Studio.
Thanks for every help, my problem was solved: I called an unmanaged function with only 2 parameters, while it had 3. However I still don't understand why it worked with debugging mode, and not without debugging.
I have no idea how to even approach debugging this issue. I have a solution with four projects in it and all of a sudden it has stopped functioning properly.
When I open the solution and click on anything, it freezes up and it says that 'Visual Studio is busy waiting for an internal operation to complete". It gives the same message when I try to build the project, although it never actually opens the file or builds - I have to end the process in order to escape.
To troubleshoot this you could start visual studio in safemode, by running: devenv.exe /SafeMode. It loads only default settings and services. If it works then the culprit is something like an extension or a third party package.
You can also start Visual Studio with logging:
http://msdn.microsoft.com/en-us/library/ms241272.aspx
For a list of other command line switches you can use, like /ResetSettings, you can follow this link:
http://msdn.microsoft.com/en-us/library/xee0c8y7(v=vs.100).aspx
Perhaps you should install the Visual Studio 2010 Diagnostic Extension, to try and capture some data that can be sent to MS for analysis.
What works for me is opening VS, opening a working project and then opening the one that is experiencing the problem. Everything works fine after that.
I've written a program that does extensive use of EasyHook. The program works just fine if I run it from Visual studio ( either in debug or release mode), but it stops working ( or better, it stops hooking) if I run it from the release folder.
The question is simple, why? I run both visual studio and the application with the same user, on the same machine, so there should be no difference...
check in your debug folder if you have any files that are not inside release folder (like .dll and so on) if so copy them to release folder! and if working then, then you probably use some external dll's or some references something like that... and you will also have to include them to your setup project!
I run both visual studio and the application with the same user, on the same machine, so there should be no difference
I can make a random guess, since you don't provide much detail, and no error messages in your question.
Visual Studio 2008 and 2010 runs elevated (if I recall correctly).
If you have not disabled UAC, then you will need to run your application as an Administrator.
Visual studio team system 2008 keeps crashing on me. Sometimes it just freezes, or certain parts of the UI get messed up or a weird popup box saying something about unable to load parameters or saying something else about memory or any other number of things.
it usually happens when I do a "complex" task like go into debug mode or do a search across of whole solution or run a unit tests or something like that.
I rebooted my machine countless time, reinstalled it VS, changed my virtual memory settings, flush my page file on every reboot and anything else i could think of.
It seems like VS runs out memory or something.
I have a powerfully machine with lots of RAM so that's not the issue
any suggestions?
You can always try some standard Visual Studio troubleshooting steps:
Clean the solution
Delete / rename all files in your solution created by VS, i.e. all .ncb, .suo, .user files
Launch Visual Studio with all add-ins disabled: devenv.exe /SafeMode
Reset All Settings: Tools -> Import / Export Settings -> Reset All Settings
Delete HKCU:\Software\Micosoft\VisualStudio\9.0 and then restart Visual Studio
Repair the Visual Studio installation through Add/Remove Programs
You might also check whether there is a hotfix available addressing your issue (e.g. KB960075 sounds like a good candidate for you), or whether you find your problem already reported on the Connect website.
The first step is to uninstall all 3rd party add-ins on Visual Studio. In particular if you have multiple add-ins as they can interfere with each other in unexpected ways and cause crashes. After uninstalling repeat your scenarios and see if this fixes the issue.
If not then it's best to consult the application log and find out why Visual Studio is crashing. The log will contain at least the error code of the crash which can searched on google or reposted here for us to take a look at.
Assuming this occurs with VS up to date with all service packs installed, you might try some of these suggestions. If you haven't tried with service packs, do that first.
What version of Windows are you using? If it is Windows 7, try launching Visual Studio with a compatibility mode and see if that resolves the issue. To do this, make a copy of the normal launch shortcut and go into the Properties dialog and set it to run as Windows Vista.
If this doesn't fix it, then you might also consider:
Checking your PATH environment for any weird settings which might be confusing it, e.g. paths pointing to other SDKs
Any 3rd party VS extensions such as source control, refactoring plugins, wizards etc.
Old versions of .NET or SQL server
Also test if the issue occurs for every kind of project or just certain kinds, e.g. does it happen for all projects? Does it happen in C++, C#, VB.NET projects etc.
You can also attach a debugger to Visual Studio, to see what it's doing. Sometimes a particular .sln will trigger bad behavior or more likely, some third-party add-on.
If you believe that you've gotten VS into a wired state, you can try the following command line switches
devenv.exe /ResetSettings (This will reset the visual studio settings to the defaults)
If that doesn't help, as a last resort, you can try
devenv.exe /ResetUserData