There's a famous bug in Visual Studio that prevents you from using the form designer on a subclass of an abstract form.
This problem has already been elucidated and solved most elegantly by Urban Potato; that's not the part I'm having trouble with. The trouble is, I have duplicated the technique described by Urban Potato, and included it in my project (which happens to be pretty big), and now every time I try to open the designer of my derived form, I get that Microsoft "frightfully sorry, old chap, but I'm going to have to kill you now" message (reminiscent of Otto in A Fish Called Wanda) that says "Microsoft Visual Studio 2005 has encountered a problem and needs to close. We are sorry for the inconvenience."
But here's the real kicker: if you just ignore that message, and stuff it away beyond the bottom right corner of the screen, you can carry on working, perfectly normally! Just don't click the "Send Error Report" or "Don't Send" buttons, coz then VS does close.
Still, this phenomenon is highly annoying, and I'd very much like to be able to work without the feeling that my IDE is just looking for some really nasty way to get back at me for pooh-poohing its sage advice to quit now - or else.
Further useful info: this same behavior can be duplicated on all other computers in my office; it's nothing specific to my machine. Obviously something in the project/code is upsetting the IDE, but at least I know the design pattern works, coz after I ignore the crash message, the designer works perfectly well. I just don't know where to start looking for the thing that is causing this problem.
Any ideas?
Thanks!
If it were me, I'd try attaching a debugger (maybe another instance of Visual Studio) to the instance that throws the error dialog, and see if the stack trace gives you any insights into what's causing the error.
The reason your are getting this problem might be that your base form is an abstracted class. The reason why the IDE will crashes is because the IDE tries to create an instance of the the abstract class which it cannot do.
It might be that you accidentally marked the internal class as abstract too.
Regards,
JvR
Related
I had an experience the other day where an exception should have been raised in my code, but instead it just kicked out of the routine and continued running (i.e. it's a WinForms project, so by "continued" I mean control just went back to the form where it waits for further user input).
I thought it was odd, but fixed the problem and didn't worry about it. Today, I had the same thing happen in a different project where I had an XmlDocument object Load()'ing a file that didn't exist. It should have raised an exception, but instead it just kicked out of the routine and gave control back to the form.
Has anyone else experienced this behaviour or know anything about what might be causing it, or does this sound like a bug in VS 2010?
I got the same issue a will back. In my case, the problem only occur in development and not after the release. To get the errors, I found the you need to change a setting in VS. In the Debug menu, click on the Exception item. This tell when VS should break with error. You need to check the Common Language Runtime Exception Throw option. It should correct your problem. You will need to do this for each project.
I want to completely remove "error list" from visual studio 2008, not disable it i want it gone. It annoys me to no end popping up endlessly, i guess i must be "doing it wrong" but w/e i just want to use VS without being alerted every other keystroke about some warning.
I've tried editing many different fields in the options (tools -> options) it has only slightly decreased the frequency of the error list popping up. I have also deselected errors, warnings, and Messages. and it pops up with nothing to display. unpinning it doesn't help either.
also upgrading to VS 2010 is not an option at this point.
Im looking for a solution something like the following: remove a dll or config file responsible for this
Also I still want the inline validation (the little squiggly marks, etc), but
the error list window annoys me.
I think this is probably exactly what you're wanting:
http://blogs.msdn.com/b/zainnab/archive/2010/05/16/hide-or-show-error-list-when-the-build-finishes-with-errors-vstiptool0022.aspx
You can change this behavior by going to Tools -> Options -> Projects
and Solutions -> General and deselecting the "Always show Error List
if build finishes with errors".
I'm guessing this will work with ASP.Net as well, since that's building on the fly.
I am using Visual Studio 2017, and I also have to cope with the useless, impossible-to-disable, annoyingly-in-your-face, and outright disturbing "Error List" window.
So, here is what I did:
Undock the "Error List" window to make it free-floating.
Resize it to the smallest size possible.
Move it out to some remote area of the screen where it is not so annoying.
And voila, problem solved ! (*1)
*1 Well, problem mostly solved. It will be completely solved when I abandon this dinosaur of an IDE.
My 'Error List' was constantly displaying also (VS2012). I also hate it.
I turned it off years ago, but today it just started appearing.
It was being caused a unreadable packages.config file. For some reason that reports it's fail state through the yukky 'Error List'.
Fixing the packages.config file stopped the 'Error List' from appearing.
for VS2017, select the "Build only" value from the drop down list in Error tab. Refer to the image below:
Hope this helps!
On Error tab, you have Errors / Warnings / Info buttons. Click on Errors button (de-press).
hope it helps.
I suggest turning off inline validation.
Yes, I know that you still want it. But, seriously, how important is it? It's trying to validate code that is half-written. How valuable can that be?
First of all, as-you're-typing code validation is distracting. It makes it harder to focus on the problem you are trying to solve. For example, writing a function with a non-void return will display the "not all code paths return a value" error continually until you get to the end of the function. In the meantime, the editor is telling you that there is a problem. I am sure that people learn to ignore these things over time (I have never kept the feature on for more than a few minutes after a new VS installation, so I don't know), but if you are actively ignoring something, then what good is it?
Second of all, any good that the validation would be capable of is unnecessary, because those errors will be brought to your attention at compile-time anyway. Having an uninitialized variable pointed out to you while you are thinking through the algorithm does not improve the quality of the code at all verses having it pointed out when you try to run the program. The variable is still going to be initialized either way. And there is an extremely high likelyhood that you are going to fix the problem before trying to run the code anyway.
So I just don't see the point of it. I suggest turning it off, and then your problem goes away.
UPDATE
As pointed out by #Charlie Kilian, there is a flaw in VS in which .aspx files are not validated at all, unless the "Show live semantic errors" option is enabled for C#, rather than validating those pages at compile-time as would be expected.
Therefore, editing aspx files will require turning this option back on for validation.
I guess I'll be going back-and-forth with it from now on. I hope they fix this in future versions of VS.
I still think that doing a semantic analysis and error-reporting on code that is actively being edited is a fool's errand. (Of course, I have also been known to write entire programs in notepad, just to see if I could get it to compile and run correctly the very first time without the crutch of Intellisense. It feels pretty awesome when it works.)
Selected answer is incorrect because unchecking "Always show Error List if build finishes with errors" does nothing to stop the dreaded Error List window from popping up on other errors, even if you change it to show only Build errors.
11 years later in Visual Studio 2022 it is still impossible to disable Error List window.
The only correct answer to the question "Completely remove error list from visual studio" is to uninstall Visual Studio itself which, thankfully, also removes Error List window.
Either that, or we should all get used to it, because Developer Gods from Microsoft want everyone to work in absolutely the same way as they do. Every workflow that differs from their own is wrong, and every thought that doesn't align with their grand vision is blasphemy.
It is One Microsoft Way or the highway.
C#, VS2010, WinForm application:
Sometimes I do have the problem that I get an error message when opening some of my controls / forms. All code compiles and the application runs properly. Opening the control in the designer gives me:
The designer loader did not provide a root component but has not indicated why.
From my experience I can tell, it is usually something in my code which does not get properly initialized, e.g. a property is not set which is somehow available at runtime, but not when opened with the designer. The only issue is, that the root cause is hard to find.
Q: Is there a chance to somehow use the debugger when the designer opens my component in Visual Studio 2010? That would help a lot and the problem tackling is most likely a matter of minutes then.
Remark: Just to make this clear, I know how to use the debugger ;-), I only have no idea how I could tell VS2010's designer to open my control in Debug mode.
As of 2nd SEP 2010 added:
Thanks for your help. Basically it is the MSDN Library article describing how to do it.
I have managed to set it up and run the second instance
(there was not much to understand how to do it).
It only fails in my case, because the 2nd VS2010 instance (debugging Design Time) fails to find the
symbols for my custom control. I have added the symbols manually under Debugging / symbols. No
result, still "Breakpoint won't be hit because of missing symbols"
BTW, using this approach it is helpful to exclude some stuff from the symbol loading (via modules window), because this will safe a lot of time.
Now if have to figure out how to get the symbols resolved and then I can tackle the issue.....
The vast majority of design time problems with custom controls are caused by code in the event handlers or method overrides in your control running at design time as well as run time. That's normally desirable, you get instant feedback when you change a property in the Properties window for example.
But not desirable when the code depends on something that's available at runtime but not design time. Like a dbase connection or a file that's stored in the build folder. That can generate exceptions and Visual Studio isn't very robust against handling exceptions at design time. Worst case, you can crash VS to the desktop without any diagnostic. But anything is possible.
Review the code in your control and make sure that the bits of code that should only run at runtime are wrapped like this:
if (!DesignMode) {
// etc..
}
Hard cases can be diagnosed with the debugging tips in this MSDN Library article.
To debug your control in design mode, you need two instances of Visual Studio. In the first instance, open the project which contains this control source code. In the Project Properties, Debugger, set command line which calls another Visual Studio instance (msdev? don't know exactly for VS2010 - take it from the shortcut), Then execute "Start Debugging" command. Another Visual Studio instance starts. In this instance open client project which uses your control on the form.
When developing AddIns for Visual Studio 2010 the following line fails:
CommandBarEvents handler = (EnvDTE.CommandBarEvents)m_VSStudio.DTE.Events.get_CommandBarEvents(popup);
Update: Forgot to tell that m_VSStudio is of the type DTE2
Where popup is of the type CommandBarPopup (for the type CommandBarControl it works though)
The line fails with this Exception:
System.Runtime.InteropServices.COMException (0x80020003): Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))
The exact same line worked in Visual Studio 2008.
The purpose of the line is to get a handler which handles clickevents, when one clicks the Popup.
After som searching I found this link: http://connect.microsoft.com/VisualStudio/feedback/details/524335/events-get-commandbarevents-exception-on-submenus-reproducible-bug-addin
Which basicly states that it is a known bug, which will not be fixed, because there is a workaround. But unfortunately it does not state the workaround :(
I would be extremely pleased if anybody has a great idea for a workaround ?
The reason why I want to listen to the click events is because I want to show or hide the submenuitems (CommandBarControl) given some condition, when one clicks a menu (CommandBarPopup).
So a workaround that uses something else than the click event would also be appreciated.
Jesper and I talked about this in e-mail. What he was trying to do was ensure that members of a popup menu that he created were in the proper state right before they were shown. He was using the Click even on CommandBarPopup (which was deprecated in 2010 in the move to WPF) to have a way of knowing when he needed to do the state updating. I mentioned the preferred method for doing this (even in 2008) would be to implement IDtCommandtarget on his AddIn class. The VS shell will call this method when it needs to find the status of commands. It will call this method at all the 'regular' times it updates command state (i.e. on idle if needed, right before showing a menu, etc..). Moving to this method works for his scenario and seems to solve his problem.
Ryan
It is unfortunate that the phrase 'our e-mail correspondance' and 'you found a workaround' was put in a public bug with no indication of what the work around was. I suspect the person was trying to do something quite different from you (even if he was using the same event mechanism to hook in), so perhaps we found a better way to do what he needed. I can't think of any easy way to do what you are doing, though if I understood why you were trying to do what you are doing (i.e. are you hiding your own commands? The commands of other people? To what end?) then perhaps we could think of something. Feel free to mail me directly, address is rmolden AT microsoft DOT com, sorry for the inconvienence. We can also follow up here with any work around we find so it will be captured by the internet rememberance machine for all time.
I've been working with Janus GridEx for Web for a few days. I'm afraid I'm unable to open the GridEx designer (Grid context menu in ASP.NET designer), which makes real work fairly impossible or at least unproductive. I get the following error message:
Error invoking 'GridEX Designer'. Details:Exception has been thrown by the target of an invocation.
Unfortunately this error message doesn't really tell me anything about the real error. In Janus Forums, somebody had the same issue. The support guy recommended to check version and Local Copy property, but this isn't the cause of the problem (neither mine nor the guy's in Janus Forum).
Thank you for any help.
Greets
Matthias
Original text of this post:
I just figured out how to open the
GridEx designer. Visual Studio needs
to be running as Administrator ("Run
as Administrator" in Vista, and
confirm the UAC message). Don't like
that personally, but it works fine.
This is right so far, the message does not appear anymore. The designer did open, but did not save any changes. In Janussys forum, support staff had not seen this behavior before.
Currently the problem is different (I'd say even worse): The designer does not open, but the message mentioned in the opening post doesn't appear anymore. Just nothing happens. UAC is still disabled, and Visual Studio running as Administrator. I completely reinstalled the component with UAC disabled.
I know that "Doesn't work!" is no proper error description at all, but in this case I just don't know better.