I am using Visual Studio 2008 and I get the following error message when trying to open one of my Forms:
Could not find endpoint element with
name 'WSHttpBinding_ICommon' and
contract 'CommonWCF.ICommon' in the
ServiceModel client configuration
section. This might be because no
configuration file was found for your
application, or because no endpoint
element matching this name could be
found in the client element.
And the following stack trace
at
System.ComponentModel.ReflectPropertyDescriptor.SetValue(Object
component, Object value) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializePropertyAssignStatement(IDesignerSerializationManager
manager, CodeAssignStatement
statement,
CodePropertyReferenceExpression
propertyReferenceEx, Boolean
reportError) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeAssignStatement(IDesignerSerializationManager
manager, CodeAssignStatement
statement) at
System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeStatement(IDesignerSerializationManager
manager, CodeStatement statement)
And yet I do have the element suggested in my App.Config and everything works at run-time. However, whenever I try to open the form I get this message, which is not too bad because I can ignore it, but when I do many of the controls (those with anchors on the right side and/or the bottom) are shifted and my grids automatically regain all the columns from their datasource which (the columns) I had previously removed.
Any suggestions/workarounds? Is this a Visual Studio 2008 bug?
There's another approach to debug the devenv process (visual studio) in design time, like stated
here
This helped when opening form in design mode throws exception (i.e. shows error to user).
Here is a summary from that article:
Open a new Visual Studio instance.
Open any source file. This is required so that Visual Studio lets you attach to a process.
Attach the new Visual Studio instance to the first one. The Visual Studio process is called devenv.exe. You only need to attach to managed code.
Set Visual Studio to break on Common Language Runtime exceptions - Thrown and User-handled.
Close the problematic form, and reopen it.
This should result in an exception caught inside your code in the second instance of Visual Studio!
Where are you using the endpoint? Do you really need it there or can you only call on it during runtime? You can use the Component.DesignMode property to determine whether you are in design mode so you can prevent the calls to the endpoint being made. To fully debug your design time experience follow the instructions in this article.
I use
if (LicenseManager.UsageMode == LicenseUsageMode.Designtime)
{
return;
}
To check for Design Mode in both the Constructor if it does anything other than InitializeComponent() and the Load Method if it has one.
I had a similar error once in a form that tried to make a database call during constructor initialization.
Unfortunately, Component.DesignMode doesn't get set until after the constructor finishes!
Related
I followed the example below for global exception trapping in WPF. In the example he throws a null pointer exception in a try-catch block and then another outside the block. The second is supposed to be handled in the app.xaml.cs file in the Application_DispatcherUnhandledException() procedure. This procedure is subscribed to in the app.xaml file with DispatcherUnhandledException="Application_DispatcherUnhandledException".
For me it does not work. Any ideas why? I am in VS 2010 and I think this tutorial is for VS 2012. Perhaps the behavior changed between versions.
http://www.wpf-tutorial.com/wpf-application/handling-exceptions/
Greg
The version of visual studio wouldnt affect this sort of behaviour.
I tried the example you linked to and it worked as expected for me.
Are you running it in Debug? If so Visual Studio will catch the unhandled exception before your handler would do (depending on how you have exceptions set up). Try running it using 'Start without debugging' and see if you hit the secind Message Box.
I am using a variation of Jeff Atwood’s Unhandled Exception handler it steps in when there is an Unhandled Exception in the application. It then logs the error, generates a screen shot and notifies the user.
When compiled in a solution the project generates an EXE that is called when needed. In updating the program I am using Visual Studio 13 to edit the existing settings items in the project properties. In the code I use commands such as this from ConfigurationManager.
string appProduct = unhandledExceptions.Properties.Settings.Default.AppProduct;
I was happy to see that it worked and reflected the changes I made in the IDE. However I couldn’t find the settings in the solutions generated confg file (MyApplication.exe.config). I assumed it was reaching back to the other project folder for the UnhandledExceptions.exe.config.
I created an installer and installed it to a virtual machine. My settings carried over, but again I could not see a config file.
It turns out the values are embedded in the executable UnhandledException.exe.
The project does not have any resources listed. Searching the web and StackOverflow looking a questions that want to do this, and there are a lot of them, it seems this was generally considered not possible and not desirable. Questions usually end in “You don’t want to do that, it’s called config for a reason”.
I may want to turn this off, so it is editable externally. The properties of app.config in both projects are identical.
What setting is making this possible after all? Is it a new capability with Visual Studio 2013?
There is no Visual Studio setting required. If you don’t want the user to have access to the configuration file, don’t include it in the distribution. One can always be added if the settings names are known.
In the description below application generically represents the name of the application being used.
I’ve found through observation some interesting things about the way ConfigurationManager works.
For User settings it will look in the following places in order of priority:
user.config for the application in the user’s AppData area
application.exe.config in the program folder
application.exe itself
Each setting is searched for individually. If your application requests a setting that is not found in either user.config or the application.exe.config it will get it from the executable.
For Application settings it looks in the following places in order of priority:
application.exe.config in the program folder
application.exe itself.
There is no equivalent to user.config for application settings.
Opening the application.exe in the Visual Studio IDE does not reveal a resource for the configuration information.
application.exe.config is handy because it can be modified externally and used as a default value for new installations. Once a setting is overridden in the user.config the value in application.exe.config is ignored.
The same is not true for the AppSettings section, the older configuration method from .Net 1.0. If I delete the configuration file it does not have them in the executable.
These observations were made with Visual Studio 2013 Update 4 and tested in Windows 7 Professional 64-bit. I suspect they are true in all versions.
Try putting the following code inside Load event handler for WinForms or Loaded for WPF.
Dim doc As New XmlDocument
Dim nsmgr As New XmlNamespaceManager(Nothing) 'this line throws an exception
Problem is that exception is not thrown, and stack corruption happens. It may have different side effects, depending on the IDE - see below.
Affected IDEs are: 2008, 2010 and 2012 (those I could test). 2010 resets stack state, and returns from sub/handler, like nothing happened (but without proceeding with other statements there). 2012 may warn a user about a failed application and an attempt to run in compatibility mode. Next time after that it runs the same as 2010. 2008 properly throws an exception, but only on default configuration (AnyCPU). Switching platform target to x86 makes the problem reappear in 2008 as well.
Affected frameworks are WinForms and WPF. Console apps and ASP.NET
seem to work fine. .NET v2.0-4.5.
Affected scope is only Load event so far.
Putting this code into a button makes it work.
Affected build
configuration = any. Tried on default Debug and Release.
Why I consider it a bug is because it can leave objects in an unstable state - they did not finish initializing, which is not an expected behavior. What's critical about it is that nobody will know it happened, as it does not throw an exception. Depending on your design, you may end up with incorrect data in your database, which in the worst case may lead to severe consequences.
Does anyone have a good explanation to why this may be happening and if there is a workaround?
The problem is caused by the wow64 emulation layer that comes into play when you target x86 platform on a x64 OS.
It swallows exceptions in the code that is responsible to fire the Load event.
Thus the debugger doesn't see the exception and cannot step in to handle the situation.
This article seems to document well what's happening there,
This previous answer from Hans Passant (to which goes all the credits and upvotes) explains possible workarounds.
My preferite one is to move everything out of Form_Load event and put the problematic code in the form constructor. (Of course I don't know if it is applicable in your case)
(see update below)
While running within the VisualStudio 2010 environment, I can easily tell if my Winform application causes an exception. I just have to go to Debug | Exceptions and make sure that both columns of checkboxes are checked. I then run the application and if any exceptions then I get dropped straight into the offending piece of code.
How do I determine exceptions during testing, when I give test build to a tester. I do not want the tester to run within Visual Studio, just as a regular user. I still want to know if there are exceptions and the pertinent details.
Obviosualy, I should be able to control the process, so that when the code gets released normal execution happens.
Yes, I know about and use try/catch blocks, but I am talking about a method similar to Visual Studio exception catcher and reporter, just possibly compiled into the product and used for deployment to beta testers.
Maybe Visual Studio has such a feature, in which case where and how to set up, or possibly a third party component.
[Update:
I added two sub-questions, which you can find at Unhandled Exception next line or exit.
The solution mentioned below sounds great and with a tweak probably works, just not at the moment.
Inside the Visual Studio both 2010 and now 2012 works great. The exception handler gets called, okay after VS breaks at the line and I say to continue. I decided to test outside the VS2012 IDE, good thing for that. The OS traps the bug, shows the standard an "An Unhandled Exception Occurred" dialog giving the details along with a continue and quit buttons. Selecting continue, just continues the application with no trapping into my uber exception handler. Selecting quite, whites-out the application and displays the standard close window dialog. The quit button also does not call my uber handler.
The purpose is so that my exception handler gets called. I do not need an uber exception handler if I am working inside the VS2012 IDE. The purpose of the handler is for end users and beta testers, namely anyone other than myself and who will not have my development station.
So unless I am missing something, the question is still open.
There are code samples in the other question, enough to copy and paste and create a test application in a couple minutes time.
]
Thanks in advance,
Sarah
I don't know of any automagical ways to reports error in Visual Studio but here is what I do.
Hook into the UnhandledException event for the application.
Use a logging framework like nLog or Log4Net to log the exception and other data you get from that event. Or just write to a text file.
Upload that data either from within your application or have the beta-tester send it to you.
Okay, the Google Uberlord took pitty upon me and I found this wonderful article solving the problem. Praise to the almighty Google.
Here is the link:
http://www.switchonthecode.com/tutorials/csharp-tutorial-dealing-with-unhandled-exceptions
Basically, JRadness had the right idea, just slightly in error. He should have used
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
rather than
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
The author on Switch on the Code talked of three methods, the first of which is what JRadness proposed and does not work for Windows forms.
The autor even solved my other question of Continue and Abort. The OS got bypassed.
Yeah!!
Background info
I'm maintaining a Winforms application in C# using VS2010. The main form has a TabControl with a few tabs. The startup object is a class with a Main funcion (nothing new here) that does nothing more than firing the main form.
The form creates a Datastore object that gets it's connection string to the DB server from a static Settings class. This class has a static intializer block:
static Settings()
{
IniReader reader = new IniReader("config.ini");
//...
}
The configuration file resides in the main project folder (same as the startup object) (and also in the bin and debug folders).
Problem
In solution explorer, when I double click the main form to open it in the designer, VS crashes with the exception mentioned in the title of this question, but also with an error stating that it can't find the config.ini file in "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE".
The problem can be resolved by copying the config file to that location, but I don't find this a real solution.
Why would VS search for the file in that location?
Strangely, the last time I opened the solution, I didn't have this problem. I haven't installed new Windows updates since then.
Remark
The architecture of the application and other design decisions aren't mine. I'm just extending the program and while doing this, I'm trying to improve on the architecture. But that's not the subject of this question.
I think you already understand that the VS designer creates an instance of the form it's trying to show, and that means it will invoke the constructor and any static constructor.
The most common pattern I've seen for avoiding this kind of problem is to move any non-trivial initialisation logic into a separate Initialise method. In there, and in any method other than a constructor, you can use...
if (!DesignMode)
{
//your code here
}
...around any code that isn't actually needed for the form to render correctly in the designer. I realise that means some refactoring of the code and you may not want to do that, but I have used this approach and it avoids this kind of problem well.