I have a small set of macros I use with my IDE for commenting, and other minor repeatable tasks. I've been using these macros for a few years.
Recently they just stopped working. I'm not getting any errors, but they appear to not be executing. I've tried opening the Macro IDE and setting breakpoints on the first line of the macros, but nothing happens.
I've been dealing with this problem for a few weeks now, so I have reboot a few times since then. I've tried repairing the IDE, but still nothing works.
Any help would be greatly appreciated.
Thanks.
Marshall
Have you looked at Microsoft KB928209 and Microsoft KB906763?
They both sound similar to the issue your are describing.
Related
Getting pretty tired of all these random bugs in this IDE. This shortcut worked fine before, and now it's not. Any ideas? I made sure I didn't map the shortcut to anything else. It just stopped working randomly. I'm using 4.0.1. Thank you.
To nip this in the bud, I have posted this question and workaround. I would like to accept an answer that actually quantitatively describes the problem.
I do some office programming using VS2010 and VB.NET. I have found that using VB.NET over VBA provides a much better user experience for office automation tasks. But, VB.NET IDE sometimes, not all the time, grinds to a halt when debugging Excel COM interop code, such as it takes 5 minutes to set a string equal to the value of cell, or just removing and adding breakpoints takes minutes apiece. This has been the bane of my existence for sometime, as I would have to restart my computer to fix it, but I have finally figured out the causal actions and a workaround. It happens when I have more than one other Excel instance open besides the COM server. I know Excel usually only opens one EXCEL.EXE, but, I have my registry settings so that every excel document opens in a new instance, so that I can look at separate docs on separate monitors. I don't believe this is uncommon. So, when I have left Excels open and my app starts an Excel COM server and breaks into the debugger, this is when the problem occurs, but also only if I click or operate in someway in one of the Excels after starting the COM server. Then it is like the COM server gets confused as a chameleon in a bag of Skittles of which it can't get out until I restart the computer. So, does anyone have enough debugging, COM, and Interop expertise to tell me what is causing this debugging hell? And possibly a way to preempt it?
To workaround this problem without restarting, I have found that I can end all instances of EXCEL.EXE, even the COM server, and close the IDE, then reopen Excel directly without a document and close it. Now, reopen the IDE, run code, start debugging, and stepping latency is non-existent or negligible.
I'm using VB.NET in VS2008 professional. Just installed Coderush Xpress 11.2.10. Code formatting and intellasist doesn't work.
I tried Edit->Advanced->Format Document but VS keeps formatting in its standard VB way without coderush configuration.
Intellasist never shows nothing. Even with intellisense deactivated in VS.
Can somebody help me? Thanks.
I regret to inform you that neither Intellassist nor Code Formatting for Visual Basic is available in the free CodeRush Xpress version.
I have just a form in my VB.Net project and even when I try debugging that - there is nothing going on besides the form being loaded - I get the error:
No symbols are loaded for any call stack frame. The source code cannot be displayed.
I've tried using this solution from StackOverflow, but this is either oudated or pertains only to C++. I've also tried using this article from the MSDN Forum, however, this also did not seem to help as I wasn't quite sure what the answer was telling me to do.
Has anybody else came across this problem and found a solution? It's very frustrating that I'm receiving this error and I only have a form showing up.
Edit: I found another solution here but I don't quite know what that means ... yet. I was going to look into this but I'd really like to know why this doesn't work when Application Framework is enabled.
Make sure you are running in debug and not release. Build>Configuration Manager>Active Solution Configuration = Debug
Get rid of all compiler warnings/errors and rebuild. Look at your Sub New() and form_load events closely. Dodgy form inheritance can cause this. Dodgy module level vars also. From memory even when you fix the problem you need to rebuild to get the designer back. Might be a my.Settings issue.
Sorry for imprecise advice, I have had this problem before but I cannot remember the details.
A quick workaround is to just uncheck "Enable unmanaged code debugging" and "Enable the Visual Studio hosting process" in the Debug section of the Project Properties.
We have 3 developers all using the same version (VS 2008 SP1) and we all use large VB projects (windows forms). From time to time, the IDE will have all sorts of issues such as locking up, crashing, and even not being able to drag a form object around or it will just instantly disappear.
On the largest of our projects (which is actually 5 projects in one solution file), a couple people here can only rebuild the project for testing 2 - 3 times before they have to close the studio and reopen it.
Has anyone else experienced this? Does this happen with large C# projects?
Yes, I experience this all the time! It has gotten better in 2008, if you can believe it.
I usually find that the reason has to do with an exception in my own code. The UI might bring in a custom control that does not behave well in design mode, causing the problem.
Sometimes, I will bring up a second execution of VS2008 and attach the debugger to the first execution of VS. Then, I can debug my own code as it is being run in the designer of the first instance. Often, an exception is thrown and I can fix my code to play better in the designer.
In other circumstances, I have no idea why it happens.
I have heard of people having this issue, however, I have never had an issue at all myself.
I have heard that a number of people trace the issues back to the use of ReSharper as the primary cause.
The most common problem I've had that causes the designer to crash is when I create a form where the only constructors require parameters.
To alleviate that, when I need the form only to be instantiated with parameters, I create a private parameterless constructor that the designer can use but which the form's consumers won't see.
I have personally experienced all sorts of designer wickedness with VS2008 sp1. I uninstalled the service pack to return stability to my dev environment. This is an unfortunate answer, but give it a try.
Only thing I've had close to this is the design view crashing and bringing up an error, formerly causing me to have to recreate the form and copy and paste the code across until I learnt how to fix it.
My problem was occurring because of me using ctrl+f a lot though. If you are using big files, this might be what's happening.