We Keep Coding

Accessing SqlCeException on Windows Phone 8

I am getting SqlCeException in my WP8 application. The message says only:
An exception of type 'System.Data.SqlServerCe.SqlCeException' occurred in
Microsoft.Phone.Data.Internal.ni.dll but was not handled in user code
As you can see, it is not very specific as to why did it happen. After some googling I found an advice to inspect the exception further by accessing its Errors property (link to discussion). However, I am not able to import the System.Data.SqlServerCe.SqlCeException into my code. Therefore in consequence I am not really able to access any more information about the exception. How can I import this exception to my project so I could work with it? The only idea I got was to add Entity framework, but for some reason NuGet fails to install it.
EDIT:
For further generations, I am still not able to access it, even the Reflections seems to reject messing with it (MethodAccessException thrown when I tried to access the value of Errors property of the SqlCeException). At least the SqlCeException.ToString() method returns quite a meaningful description.

You can't connect to an SQL db from Windows phone, the best way it to create a REST Web Service which connects to your db and start consuming it.

Exception Handling Logging using Enterprise Library

I'm relatively new to Microsoft Enterprise Library. I'm currently explore using Enterprise Library 5 to do logging on exception thrown by the system into a text file.
Question 1
I came across LogEntry in Microsoft.Practices.EnterpriseLibrary.Logging comes with ErrorMessages and Message.
I hope that you all able to explain on which circumstances should use either ErrorMessages or Message? I can't find any definition on those two variable at the moment.
If I caught an Exception, should I assign ex.Message into ErrorMessages or Message?
Question 2
I also found out that there are Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging. May I know is this a more proper way to log exception instead of using Microsoft.Practices.EnterpriseLibrary.Logging?

If your purpose is to handle/log exceptions then you should be using the Exception Handling Block (of which Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging is a part). The EH Block allows you to configure how different types of exceptions are handled and create categories of exceptions. Then, when you need to handle an exception, you simple need to call:
ExceptionPolicy.HandleException( ex, <NameOfPolicy> );
The library will take care of the rest, routing the output to the correct listeners.
In addition, the EH Block has built-in functionality for fall-back logging. Let's say you're trying to log to a database but the database cannot be reached. You can configure the EH Block with a fallback (out of the box it uses the Windows Eventing system) and the fact that the log couldn't be created and the original exception will be logged to the fallback.

May be too late but if in-case it helps someone.
You shouldn't use Microsoft.Practices.EnterpriseLibrary.Logging directly to log errors. It should be used only for general information logging.
Use Microsoft.Practices.EnterpriseLibrary.ExceptionHandling and Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging for error handling and error logging and configure it that way so that it uses one of the logging policies to log the error. What will be written in your log is depends on how your formatter is configured and where it will be logged is depends on your listner.

For the first question,
You mostly use Message, ErrorMessages is more of extra information.EntLib ErrorMessages
For the second question:
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging
it sits on top of Microsoft.Practices.EnterpriseLibrary.Logging, it mostly formats the string to be log-ready, so using it to log exceptions is optional and depends on your logging strategy. For example, I use Microsoft.Practices.EnterpriseLibrary.Logging to log everything, only cause I prefer working with minimal external references and the differences between the two is not that much.
LoggingExceptionHandler

How to report standard exceptions to the user?

Consider a C# GUI application which uses a FileStream to read a file, chosen by the user through an "Open File" dialog.
In case the read fails with one of the exceptions, what is the correct way to report the failure to the user, in an user-friendly manner?
Should I invent my own message for each of those exceptions, or is there a way of obtaining a localized, user-friendly message that I could present verbatim to the user?
Edit
I'm asking whether .NET itself is able to provide me with a descriptive string that I can present (and which would be consistent with other .NET programs). I know that I can roll up my own, but I'd like to avoid that if there's a standard alternative.

You can have a set of localizable user exceptions with one of them being say FileUploadError. You can put a localized general information there. Throwing a few technical details might be a bit challenging, as it can be quite hard to get the right balance between technical details and a simple step that a user needs to take to fix an error.
My suggestion would be:
Have one user level FileUploadErrorException
Have a details property in it
Depending on the actual exception, suggest a user to try a few things

If you are catching an exception thrown by one of the .Net framework's File classes, then it is likely that the contents of the exception's .Message property will already be localized. The .Message property is supposed to contain localized, human readable text. How 'friendly' it is depends, I guess, but it might contain something you can embed within a more general and friendly paragraph.
Assuming you might write some method AlertUserWithMessage() to display the error to the user, this might be useful:
try
{
fileStream.Read(...); // or some other operation
}
catch(Exception e)
{
AlertUserWithMessage(e.Message);
}
If you want to include additional information that might be helpful to a support person diagnosing the problem, then you can also get the stack trace as a string from the exception.
try
{
fileStream.Read(...); // or some other operation
}
catch(Exception e)
{
AlertUserWithMessageAndStackTrace(e.Message, e.StackTrace);
}

Exception messages are by nature technical and describe what went wrong (at implementation level), as opposed to how to solve an end user's problem. On the other hand the intent of an error message presented to the user is to explain what failed and what action to take to remedy the problem. Exceptions messages and end-user error messages don't have the same purpose and aren't written for the same audience.
So for decent user experience, it is much better to map these exceptions to localized user-friendly advice on how to get around the problem. Sure, for technical users it could be nice to have some diagnostic feature that could give details of the exception (in which case having exception messages in English doesn't matter that much--English is really the world's technical language), or just point them to a log with all the details. But just throwing an exception message, even localized, at an end user is likely to baffle them.
For this reason I don't think localizing exception messages is much use. It's true that the .NET framework has localized exception messages for major languages, but I think that's more because there are developers who use these languages as their base language and do not necessarily have a good command of English. So the audience of these localized exception messages is still developers, not end users of a software product built in .NET.

Send Email in Global Exception Handler?

I want to add global exception handling code to C# WPF apps and, although it seems rather rakish (nobody else seems to do it), I want to send email to the developer with exception info. The main problem I can think of happening here is if the developer ends up changing his email address after the software has been deployed. Perhaps an email to the department (such as a listserv type of email broadcast address) would be more appropriate? Has anybody used this sort of methodology, and if so, what solution have you come up with to make sure that somebody gets the exception-generated email?
Is this the best solution:
// in exception code (pseudocode)
try
SendEmailToTheCoder();
catch
on EmailAddressNotValid:
try
SendEmailToTheListServ()
catch
on EmailNotSent:
LogExceptionDataToLog("Bla");
...or has my brain gone pear-shaped again (I don't know what that means, but it's British, so it must be wickedly funny)

The best thing to do is to keep the details of the messaging outside of the application.
For instance, you may log errors to a text file or some other kind of log, then have an external application or Windows service monitor that log and decide what to do -- such as sending an email, or creating a digest of all messages of the day and emailing it, or a similar action.
This way, you can optimize and modify what happens in case of these errors, without having to change your program code. You can also reuse that system with other applications that also just log errors to a text file, which has a lower probability of error than connecting to an SMTP server and sending a message.

I would just create a distribution group, something like developer#yourcompany.com and add people responsible for the program part of that distribution group. If one developer leaves the company, nothing in your code needs to change and no trying one thing first and then another one.
Better yet, use a logging framework such as log4net (nlog is also popular); you can configure it to log to different places (xml, database, email, etc). If you do log to email, I'd always send it to a distribution group, anyway, even if that distribution group is composed of only one member.

Sensitive information in Stack Trace

I am wanting to discover what possible standard .net exceptions can cause stack traces to include sensitive information.
It is my understanding (correct me if I am wrong) that if a SQL connection fails then the exception message created will include the connection string which in turn might include the user name and passowrd (if not using integrated security).
We log the exception message out to log files that might be read by people that should not see that information.
What other exceptions can include information such as this that you know of?
The application in question uses Web, WCF and DB (SQL Server).
Thanks

Personally I don't think that you are going around this the right way. Trying to identify the number of exceptions that could have information in them is going to expose you to risk more than likely as one item will get missed, it just happens.
I would switch focus a bit and try to identify where you can log them to be a secure location.
Another unknown to think about here is that you could have a message created by a developer that contained sensitive information, and identifying those would be very hard.