Hey guys, I am trying to add the capability of my Windows Form application being able to send me an e-mail message when my application generates an error message. How do I setup a web service for my application? Any feedback would be greatly appreciated.
You don't need a web service for something like this.
You can use the MailMessage class from the System.Net namespace - the trick is to use the correct SMTP server settings, possibly with the SmtpClient class. This is something you will have to get on your own - from your network admin or ISP.
Take a look at the Enterprise Library Exception Handling Application Block.
The Exception Handling Application Block is designed to address the most common tasks developers face when they write applications that use exception handling. These tasks are arranged according to scenarios. Each scenario gives an example of a real-world situation, discusses the exception handling functions the situation requires, and shows the code that accomplishes the task.
The goal of arranging these tasks according to scenarios is to give the code some context. Instead of displaying an isolated group of methods, with no sense of where they can best be used, scenarios provide a setting for the code and describe situations that are familiar to many developers whose applications must handle exceptions.
The scenarios are the following:
Logging an Exception
Wrapping an Exception
Replacing an Exception
Propagating an Exception
Displaying User-Friendly Messages
Notifying the User
Assisting Support Staff
Shielding Exceptions at WCF Service Boundaries
You don't need a Web Service to send emails.
If you really want to use a web service, I would think you would actually create the web service on a server that will listen for message from the client. You could setup the windows form application with a WCF client and setup a WCF server to receive messages, but I think this is overkill.
I personally would use the log4net framework and configure an SmtpAppender to send emails when you log an error. It's really elegant when you get the hang of it.
Related
There are several XmlWriterTraceListener-s for each WCF server component.
When user do some action logs are written in different e2e files according to each component. Now we can roundly associate records through separate log files by time-stamp. But it doesn't guarantee accuracy.
The example when such logging is needed:
Some function is evaluating on server and writing logs. We want to know from which client this request was come. Because several clients may work at one time.
May be we should link calls from different components for somehow?
E.g. use something like "token" or "guid" for each callback from client and then bind events from different logs by it?
Is there maybe any standard option for configuring WCF logs?
Yes, there is. This is called activity tracing and WCF supports propagating activities. See more here: Configuring Tracing
As far as I understand your client sends multiple requests to different WCF services in your server. In this case you need client to generate activity ID, then set it as current (use Correlation Manager class) and configure your bindings to propagate activities (see link above).
Background
I'm troubleshooting some issues with a .NET Web API 2 service. The issues are inconsistent, and from the requesting service, all we see are Connection Resets and Socket Exceptions. It is not even hitting the User Code/logging in the API, but for low level exceptions that doesn't rule the WEB API out as the culprit.
Research
A very useful tool in the past for troubleshooting similar issues in WCF was enabling WCF Tracing. I'm looking for an equivalent that can show the low level Service Trace for the Web API.
I've found Global Error Handling and I've used packages like Elmah in the past. but to my knowledge this only shows unhandled exceptions, as opposed to the entire trace of the Service like the svclog does.
I also know about Fiddler and Wireshark, and while these are excellent tools for http tracking and low level protocol sniffing. At this point, I'm interested more in what the .NET service thinks it's receiving and how it's processing those actions, rather than if packets are making it over the wire.
Summary
Is there an equivalent for Web API 2 to WCF .svclog? With particular focus on the low level service interactions with bytes/requests.
Edit
I have accepted the best answer, both answers pointed to the same form of tracing. It's worth mentioning, that for this specific issue the tracing did not show any additional information, however I do believe it is the closest tracing Web API has to WCF svclog.
There is no direct equivalent solution in WebAPI but they have added some tracing capabilities in V2. You can refer to the article below.
Tracing in ASP.NET Web API 2
If you have connection issues, I would also check the IIS logs and the httperr logs that may give you more details on such issues.
WCF and WebAPI are night and day different. WCF has a complex messaging infrastructure, with lots of middleware that requires the level of tracing they supply to troubleshoot.
WebAPI on the other hand is quite simple, and there is very little that sits between the request itself and your code. Any problem in that code presents itself as YSOD (ie a 500 error, which if custom errors are disabled will show the exception). Just like an MVC or even standard ASP.NET application.
Now, there is some tracing available, but it is not to svclog's like with WCF. There is information here:
http://blogs.msdn.com/b/roncain/archive/2012/04/12/tracing-in-asp-net-web-api.aspx
You will have to write your own logger, although maybe there are some loggers out there you can find already.
Recently a couple of WCF services have been introduced to our company's API.
There are sample implementations for Windows that make use of proxy codes generated by Visual Studio 2010 (either full WCF client or Silverlight code). All looking nice.
Then I figured out that it is also possible to let Studio generate a Webservices 2.0 client code proxy and what can I say:
It works just as fine as the WCF client
It also returns real objects, just like WCF
It is also using SOAP
What the heck is the difference/advantage of a native WCF client?
Please note that I'm especially interested in the CLIENT SIDE. The server side is a different story. The point is: why would I connect to a WCF server using WCF client code if Web Services client code works as good?
I can also ask with regards to MONO: WCF support in Mono is far from being perfect, while WebServices 2.0 are woking pretty well. So after fighting with WCF for a while I switched back to a WS 2.0 client code proxy and have not noticed any issues so far. Are there problems I will have to expect?
Flexibility.
Today, you're hitting that service via HTTP. Tomorrow, you might want to add some persistance and hit it via MSMQ. Using WCF that's a configuration change - using Webservice client code you're looking at a complete rewrite of that area of your code.
Another benefit is the ability to turn on tracing, message logging and diagnostics with nothing more than a configuration change.
See Administration and Diagnostics, which says
Diagnostics Features Provided by WCF
WCF provides the following diagnostics functionalities:
End-To-End tracing provides instrumentation data for troubleshooting an application without using a debugger. WCF outputs
traces for process milestones, as well as error messages. This can
include opening a channel factory or sending and receiving messages by
a service host. Tracing can be enabled for a running application to
monitor its progress. For more information, see the Tracing topic. To
understand how you can use tracing to debug your application, see the
Using Tracing to Troubleshoot Your Application topic.
Message logging allows you to see how messages look both before and after transmission. For more information, see the Message Logging
topic.
Event tracing writes events in the Event Log for any major issues. You can then use the Event Viewer to examine any abnormalities. For
more information, see the Event Logging topic.
Performance counters exposed through Performance Monitor enable you to monitor your application and system's health. For more
information, see the WCF Performance Counters topic.
Hi
is there a way to write a logger can log the exception occurred in another program written also in c# ?
Yes, but it's not easy.
If you are running the application in an AppDomain from your current application, it's relatively easy. What you do is of that domain, you attach to the UnhandledException event handler and register the exceptions that way.
However, I suspect that the C# application you are referring to is running in a different process. In that case, you are still using roughly the same mechanism, but it's a lot more difficult to actually get the AppDomain. This involves managed C++ and executing a thread in a remote domain. You can look at Can I inject a thread in a remote app domain from C# and http://social.msdn.microsoft.com/Forums/en/winforms/thread/e4cfa5dd-e254-4088-8754-09dc40d4fb5b for more information about this.
Exceptions are a mechanism that exists strictly in-process, so no.
Upon an exception you could send the Exception details to another application which is responsible for logging the Exception. You could use one of a variety of Remote procedure call mechanisms such as might use web services or Windows Communication Foundation (WCF).
Here is a good example of Error Handling Extensions in WCF.
I'm programming a monitoring application that needs to display the state of several windows services. In the current version, I can know whether a service is Running, Stopped, Suspended or in one of the pending states. That's good, but I'm wondering if there is a way to test if a service is actually responding? I guess it can be in a running state but not responding at all!
I am using the ServiceController class from System.ServiceProcess. Do you think that if a service is not responding, the ServiceController.Status would return an exception?
How would you approach the problem?
Thanks
EDIT
Seems that: ServiceController.Status can return 2 types of exceptions:
System.ComponentModel.Win32Exception: An error occurred when accessing a system API.
System.InvalidOperationException: The service does not exist as an installed service.
Nothing about reactivity.
This might be obvious, but have you tried talking to the service?
There's no common way to talk to a service, so there is no way Windows can interrogate whether the service is still responding as normal. It is perfectly normal for a service to go into a complete sleep waiting for external I/O to happen, and thus Windows would not get a response while the service is actually alive and functioning exactly as designed.
The only way is to actually send a request to it, and wait for the response, and for that you need some inter-process communication channel, like:
Network
Named pipes
Messages
Basically, if you need to determine if a service is able to respond, you need to check if it is responding.
The service controller types and APIs can only provide information on the basis of the service's response to those APIs.
E.g. you can create a service which responds to those APIs correctly, but provides no functionality on even numbered hours.
In the end you need to define "responsive" in terms of the services functionality (e.g. a batch processor is processing batches) and provide a mechanism (A2A API, WMI, Performance Counters) to surface this.