I am writing a WinForms app which will execute some web UI tests written in a web testing framework.
Is there a way I can get the error on the page being tested (I specify the page through a method parameter) without screenscraping the page? For example, if it throws:
A potentially dangerous Request.QueryString value was detected from the client
How can I detect this?
EDIT:
One way would be to scrape just the title.
I would actually suggest you look into something called ELMAH. If you put ELMAH on your ASP.NET website it will automatically log and handle all the exceptions that get thrown by your app as you are testing it. You can have it store all the entires as XML files or in a database. You can also have it email you directly with a copy of the Yellow Screen of Death (including stack trace).
This would be a lot easier for you then trying to program the same functionality into your winforms app. Just use your app to beat the ASP.NET site up and let ELMAH handle the error logging.
What about trapping the error at the Application level (with a global handler in .asax) and sending the exceptions data to a db?
Which you can then query.
Hmm, or even, implementing a WCF dual binding, that you call the clients listening on, when an error occurs. Your windows form can be a proxy waiting for notifications. But maybe, that might not be a good idea, as you would want to have your test, separate from your application.
What about using something like Enterprise library to log to an MSMQ, which you can be listening on via the windows form?
EDIT - the ELMAH suggestion above looks good as well
Related
I was not quite sure how to phrase this question.
What I want to do is create a simple server type application in C# which simply listens for incoming socket connections and handles them the way I specify. It could be a chat application or something like that, very simple.
I looked at the example: http://msdn.microsoft.com/en-us/library/fx6588te.aspx about asynchronous sockets.
I understand the code in the example except I'm uncertain about how the code would execute. Specifically, what would be the entry point of the application in the example? How would the server know to start it?
My only experience with IIS is in web forms with C# codebehind. I understand that the code for web forms is executed when the url points to the location and then again on postbacks etc.
Where it gets foggy for me is when I don't want to use a web form but simply a collection of C# class files with a single entry point (similar to a java application).
Edit for clarity:
The goal of what I want to do is to create an application which I can put on my web host which will continuously accept requests from client applications and handle them the way I will specify and then return information to the clients. I'm just not sure how to tell the server to start the application since I only know about web forms.
Also, it would be fine if I needed to initially direct my browser to a web form and, say, press a button to start the application. In fact, it would be ideal if I could start and stop the application at will.
Also, I may have used incorrect terminology. I thought IIS servers were what you called a server which can run asp.net applications. I could be very wrong about this.
Thanks.
you cannot use IIS to start windows applications, you need a windows service application that constantly listens to the port specified, and that windows service application needs to be scheduled to start either at system start up or at any event of your choice. and that windows service applications needs to stay in memory as long as you want your app to function.
PS: your question seriously needs some editing, but I am also new to SO, so I will let respectable senior users to do what they are best at.
EDIT: If you want to simulate windows service using IIS than here are your closest bets, please follow the links to know what you need to know.
Simulate Windows Service Using ASP.NET App
Forcing your Application to Stay alive
These two links will help you keep alive your application and bamm, you can create any number of classes (Java style as you quoted) to perform whatever tasks you want it to perform
It sounds to me like you don't want to use IIS at all. IIS handles the listening for you and is the "service" to manage requests. If you are lookng to manually listen for incoming connections, then you will need the following components:
A windows service running that has..
A http listener built into it.
Take a look at the C# HttpListener class and look at the process for building a window service that can run in the background of your server.
This isn't all that difficult, but I'm not so sure it's what you need. If you don't want to use webforms, you can have a web application that resolves requests straight to custom handlers which i THINK is what you're actually looking for and makes having your own listener overkill.
EDIT: Additional info on custom handlers
Here is a start on what a custom handler is and how to use it:
http://support.microsoft.com/kb/308001
I would also look at some beginner articles on MVC3 from .net. MVC is a framework that doesn't have any of the fluff (such as viewstate) that webforms has and allows you to route a URL (request) to a Controller (class) and return pretty much anything you want. There are a lot of advantages to using MVC and if you are coming from a java/pure http background it will make much more sense than webforms.
You can get started with that one by searching around for "getting started with .net MVC3" or even start with www.asp.net for beginner resources.
Unless your goal is to learn low level TCP communication, writing and configuring services, dealing with code changes, writing own serialization/request parsing than sticking with IIS and HTTP maybe easier approach.
There is no need to use WebForms - WebService (ASP.Net or even WCF) or MVC Web API will give you ability to implement methods you want without need to write your own custom serialization and request parsing infrastructure. You can even do long poll if/when needed (i.e. SignalR).
I'd start with basic MVC application reporting JSON results as server side as it will still show all issues involved with writing chat client (persistence, discovery of other clients, quick status updates) while allowing you to focus on communication itself (including easily see all traffic if need).
I have a.NET (C#) WPF application which run on different clients.
I would like to track the usages, metrics, error, etc. of the application (with the clients permission off course) and have this information be sent back for further analysis.
I'm talking something like Google Analytics but for a client application and not web site.
I'm currently looking for very basic stuff like errors and crashes of the application, application start, application exit and because my application is build with navigation (not SDI or MDI) when a screen is navigated to and when navigated away.
Because this is a client application, and some clients are not always connected to the internet I think I'll have to cache the data and send it once connection exists.
Has anyone seen something like this (that cost less then 100$) ?
Do anyone else is interested in such ability?
Thank you very much,
Ido.
I developed something that basically did what you want on a project once. I just used an AOP library (I think I used PostSharp but there are quite a few libraries out there now that are free) that tracked when a form was opened/closed, when errors were thrown, etc. We just stored the info in a text file which was uploaded to an FTP server when the application was started the next time. We mostly used it for error reports (it only sent if the application crashed) but you could do something like that for metrics gathering purposes.
Web service error response (code/message etc) would you store it in a database? or would you keep the error response in a method.
By the time I'm done with this, there will be hundreds of error response, maybe in the future, thousands? (I dont know yet, depends how large this web service grows).
EDIT: error response is the response returned back to the application via the web service, (not to be confused with error logging).
Error codes aren't designed to look good in UI when something goes wrong. Their main goal is to inform application what happened so that application could react.
If you move the error codes to the database you'll not be able to handle them unless you'll make a standard procedure of handling EVERY error code (for example log it and shutdown the application).
Does this ever happen to you?
You are sitting at your development machine and you are made aware of an unhandled exception in a deployed asp.net application. You visit the deployed web app. You can't see the exception detail in your browser, because custom errors is set to remote only. So you have to login to the web server and instigate the exception.
Is there a built in way to turn custom errors off for certain remote clients?
This only happens to me for trivial applications where I haven't implemented a better solution, like ELMAH. But, it's still annoying when it happens.
2 things. One, if you dont have a sophisticated Exception\Logging Policy already implemented, check out the Microsoft Patterns and Practices Enterprise Library - http://entlib.codeplex.com/ - this may be helpful in tracking down bugs in your software.
Secondly, at the very least, put some logging in your global.asax code behind's Application_Error event, you can capture the last unhandled exception by using something like:
Dim lastError As Exception = Server.GetLastError.GetBaseException
Then you can add custom error pages to your web.config and not worry about debugging from a yellow screen, but still capture any error details.
HTH
You can use remote debugging.
This MSDN Article discusses debugging strategies for ASP.NET. If you scroll down to the "Local and Remote Debugging" heading there's some information for you and a link to the remote debugging article.
Basically you can debug a remote server in visual studio. Not reccomended for production servers, but staging servers for sure.
I have a project consisting of a windows client (approx. 150 users), a webservice and some windows services. All together working in an intranet and build using C# .NET 3.5. Now I want to log exceptions in a central database and manage them (watch top 10, ticket system, etc.) via a web application.
I thought about using and expanding ELMAH, because it already has an web application for management. Maybe create a webservice for the clients to log their exceptions.
Is that a good idea, because ELMAH is obviously intended for asp.net web sites only.
I am aware of the Exception Management Application Block, but as far as I know it has no management application like ELMAH, plus my last visit at the Enterprise Library was no fun.
What is your opinions, are there other ideas?
Enterprise Library is cumbersome and overkill. Look at open source logging components: NLog link text or Log4Net link text. They both have the capability to log to various "sinks" including a flat file, UDP, database, etc.
I would set something up where your logging component writes to the event log on the server. Then use something like Microsoft Operations Manager (MOM) or another systems management software that can scan the event log and raise alerts via paging, command-center console, etc. At the same time, you could also log to a database for querying, etc.
If you are looking for management of exceptions, reporting, alerting, etc... There are tons of solutions like MS MOM, Tivoli, CA Unicenter, HP OpenView, and even NagIOS that you could use for this.
The client-side is a bit more tricky. Since it is intranet, you could use UDP and run a service on the server that will listen for those UDP packets and store them in the event log and/or a database. Or you could add some methods to your web service to capture logging events.
I don't think that your idea to expand ELMAH is a bad one at all. Having done many similar projects I've always had to roll my own management apps and it is always a pain. Not sure how much you will be able to use from ELMAH but it sounds like it might be a great starting place.