In my opinion there are two situations which REQUIRE the creation of your own exception class. 1. You have a business or data layer checking errors from data entry and throwing an exception. Example: Customer name is missing. By having an exception class specific to your application, the user interface can then create custom error messages attach them to the appropriate user control and display them in a user friendly way that is specific to your application. This also allows for easy implementation of internationalization (localization) by allowing you to create a module that will pick the language specific error message for each individual situation. You don't really want to do that kind of localization at the lower levels. 2. You are implementing a service that crosses machine boundaries. In that case, you want an exception class that serializes well and provides the necessary detail to both debug any situation and to provide sufficiently detailed error messages that will be useful to the end user. Personally, I am still trying to get used to the idea that throwing exceptions is an appropriate coding practice at an application level. I come from an assembly language and UNIX background where "exceptions" were machine-level faults that totally destroy the application code context, so it was something you would never do in application code. But in the .Net world, throwing exceptions is just as appropriate for handling application errors as returning an error code would be in the UNIX world. Robert Tanenbaum

I love Linq to SQL for the queries, but it is an absolute dog when doing inserts or updates of very large transaction sets. For example, my application requires doing about 60,000 inserts as a single transaction. Using SqlCommand it takes 20 seconds. Using Linq to SQL it takes 200 seconds. I believe that because of all the checking for Foreign Key integrity it actually grows exponentially as new items are added to the transaction. As for Entity Framework, I am also using VS 2008 and would not want to use Entity Framework until VS 2010 which has a more stable and mature product than the one with VS 2008. Also since ADO gives me so much better performance for my very large transaction set, I don't think the time taken to set up an experiment with Entity Framework is worth the effort. Robert Tanenbaum

you mentioned that you upgraded from VS 2008 .Net 3.5 to VS 2010 .Net 4.0 and that the problem is in some COM code. Go back and check your reference assemblies. Many reference assemblies have different .dll versions for 3.5 versus 4.0. Be sure you are using the updated assembly. Good luck. Robert Tanenbaum