You bet!
It has been a lifesaver: I am in a situation where there is a custom developed legacy application whos datastructure and user interface is very… well leaves something to be desired.
I have built a replacement for part of its front end using a .net c# winforms app. I have had some very difficult challenges to overcome in terms of twisting the legacy datastructure into something that can be used in a more modern object oriented approach, and something that the users can work with from a UI perspective that doesn’t waste so much of their time and hair…(from pulling it out in sheer frustration)…
Fortunately, using the design pattern approach, and in particular Martin Fowlers domain design pattern (to seperate the mapping of the cludgy datastructure to my domain layer) I have been largely successful in getting it all working.
However, I ran into some really nasty issues on both the database side and the UI side.
The end platforms I am distributing the app to are highly varied, both in terms of OS (win 98-XP) and connectivity, and some users were experiencing exceptions that I could not reproduce on my machine.
I needed a way of getting all the execption details sent to me: using your handler I was able to pin down the source of the exceptions.
Turns out one was the dreaded winforms SEHException relating to the visual styles bug (mostly seemed to hit windows 2000 machines that did not have all the service packs in place).
Another was related to the speed/memory of the host machine triggered by auto-displaying a third party component combo box with a large number of items in it, which is why I couldn’t reproduce it on my machine.
The last major issue was the fact that the legacy application database is not using proper primary keys and identity constraints - the developer is using a maxID+1 approach. That one is a bit of a long story…
The other bugs I fixed very quickly once I knew what they were, and the last one - well, I was able to use the exception information to show the legacy developer that in fact the problem was due to flaws in the database desgin, and not my application…
Sorry for the long message: at any rate -
I will add the XML attachment thing first to your library, since that will be easier to do than build up the handler for the enterprise library.
Your handling approach is so good, I think it will a very worthwhile addition to the enterprise library, which I am also finding very useful (the new version is very good, and has some key timesaving features). I will likely have to wait to tackle that excercise though, simply due to time constraints. (new baby on the scene in addition to the new job)
I am working in c#, so I am not as familiar with the VB side, but I think I can get it working. Your code is very well structured, so that makes it pretty easy to understand.
I will send you the code as soon as I get it working… I will also post up the email receiver processing component and exception manager database structure, once I get it cleaned up enough for public consumption.
The receiver I am hoping to setup as a service that simply listens for email coming in on a specified address (I have it working as a winforms app, but have some multithreading issues to solve yet: still struggling with threading :-).
When an email comes in, the subject will tell the receiver service factory what handler to generate. The factory will create a handler that has all the details for extracting the contents of the attachment, and routing the information into the relevant database. I am already using it for handling scada data information - so I just need to write a handler for the exception XML, and add it to my factory.
Course you could use Biztalk for that bit, but we are running tight budgets for software so I can’t get the justification for bringing in another expensive server product. If I can get it cleaned up enough, I’ll just throw it up on the web, and hopefully other people can benefit from a simple email attachment to database processor.
It uses the CSphere email component to do the mail handling. Csphere is open source as well - these tools have saved me a lot of time, so I am keen to contribute back, which is why I plan to release the code to the community.
The final peice of the puzzle that I mentioned is geared towards automating the tracing down of information regarding potential causes of exceptions…I have found that the exception messages are useful, but not the end of the story, and that I spend a great deal of time looking up what paths an exception might stem from.
I have what I think (hopefully) is a good idea for that…