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.
Related
I'm just wondering if anyone has ever seen this exception? I'm using the C# driver and have successfully run this code on many servers. We are seeing this on one particular production server.
The first time I see this is on the first insert into a new collection. After that it seems to occur each time I call InsertBatch for that collection.
I've successfully called InsertBatch on other collections successfully during the same run.
Error** Message = The type initializer for 'MongoDB.Bson.ObjectId' threw an exception., Stack Trace = at MongoDB.Bson.ObjectId.GenerateNewId()
at MongoDB.Bson.Serialization.IdGenerators.BsonObjectIdGenerator.GenerateId(Object container, Object document)
at MongoDB.Driver.MongoCollection.InsertBatch(Type nominalType, IEnumerable documents, MongoInsertOptions options)
Thanks,
Paul
Check your inner exceptions. Since Mongo does not implement FIPS and that's mandatory in some operative system configurations, you might get this error even with authentication disabled while trying to read or generate an ObjectId (since they have an encrypted id value). To solve this problem either replace your encrypted "_id" field values on your collection, or modify the Windows registry to allow applications not implementing FIPS.
I have seen the same error on PHP today. Found out that it was a known issue (see https://jira.mongodb.org/browse/PHPC-460). I know this is C# but maybe it is a similar problem.
It is interesting with BSonId serialization which has implemented at 2013 from someones
https://github.com/SharpRepository/SharpRepository/issues/56
In my case downgrading Asp.net Core 3.0 to 2.2 has worked out.
I think mongodb.csharp driver needs to System.Runtime.Serialization.Formatters reference
at 3.0 version
https://github.com/dotnet/core/issues/2611
And an update will come on second separate of 2019
https://github.com/mongodb/mongo-csharp-driver/pull/372
As the title states, I'm looking for a way to tell the difference between an error caused by my code or basic CRM functionality and an error thrown by any custom plugin that may be installed on the clients system.
Something we continuously fall victim to is our clients custom third party plugins that either they created in house or bought from another ISV. They register it on a CRM entity we touch or even on one of our own entities in the most recent case. We try to do something, the plugin tries to do its thing and fails. In the most recent example, the plugin wasn't encoding a ' correctly after we put it into CRM. The plugin throws an error and CRM throws it back to us.
How can I tell that the plugin is the culprit without wasting hours investigating? So far I've only seen one company make it easy to tell by throwing the plugins stack trace as the error message.
EDITS FOR CLARITY:
I'm looking for a programmatic solution to cut down on the time it
takes to identify the issue is a custom plugin and not our code
interacting with their CRM from Azure.
I am attempting to enhance our error logging/handling to be smart
enough to tell the difference.
Even if our code works 100% but triggers a synchronous plugin to fire
and that plugin fails, we get an exception from CRM.
Everything we do is programmatic via the SDK.
The only thing that comes to mind is to enable CRM tracing. The link below should explain how to do this in Microsoft Dynamics CRM.
http://support.microsoft.com/kb/907490
When there is an exception caused by a plugin as this picture:
you can download the log file, inside you can easily find which plugin caused the exception, check for example this log:
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: StupidPluginDetail:
// ... other details
[StupidPlugin: StupidPlugin.ExamplePlugin]
[bda9ad85-c4a5-e211-bc00-78e7d162ee67: StupidPlugin.ExamplePlugin: Create of orderclose]
</TraceText>
</OrganizationServiceFault>
Have a look at Detail.TraceText property of exception returned by service. I haven't managed to get full stack trace, but it returned some info indicating where things went wrong:
Mario.CRM.TestOrg.Plugins: Mario.CRM.TestOrg.Plugins.ContactPreUpdate
[5ee31a9e-3558-e211-adeb-00155d014401:
Mario.CRM.TestOrg.Plugins.ContactPreUpdate: Update of contact]
Sample code snippet
try
{
//create service proxy and call service
}
catch (Exception ex)
{
Console.WriteLine(((System.ServiceModel.FaultException<Microsoft.Xrm.Sdk.OrganizationServiceFault>)(ex)).Detail.TraceText);
}
This wouldn't be recommended for use in a production environment, but would be extremely beneficial for a testing environment. Whenever a CRUD operation fails using the SDK, you could programmatically disable all plugins, and attempt the same operation. If it succeeds, enable the plugins one at a time until it fails. Then you'd be able to determine which plugin it is that is causing the issue, or whether it is not a plugin at all.
I am fairly well versed in using localization in a simple WPF UI application.
I am now in the process of developing a WCF client/server architecture; I want to be able to create various types of exception in the server, and have the error message in the culture of the client.
This seems straightforward enough - somehow we will identify the culture being used by the particular WCF client at the time.
However, I want the messages to potentially also be logged into the server's logfile in one language (typically English) to allow easier support of the application.
There are various assemblies used in both the server and the client side; each assembly is going to have a string table of error messages. Therefore when an exception is created, it needs to have the resource ID and the resource manager for that given assembly to hand. Without sub-classing each available exception type, I cannot see how to get around this. This seems like a lot of work for a problem that has surely been encountered before?
Example
Server.A.dll
Error Resources: MyErrorString1, MyErrorString2
Resource Manager: ResourceManagerA
Server.B.dll
Error Resources: MyErrorString3
Resource Manager: ResourceManagerB
So ideally I need to have access to the resource manager for a given string at the time I need to either log the message to the file or send it back over WCF as a fault; but I don't want to lose the ability to catch types of exceptions by using one generic exception class.
Does anyone have any experience of this problem, or any cool suggestions on how to go about implementing it?
Thanks in advance,
Steve
I don't think that is good idea to show plain Exception messages to users. Instead, I would catch them log them and show friendly message in UI. That way you won't need to subclass anything...
If it is a technical exception, there is no need for details that the user won't understand anyway. Just display a generic error message.
As for expected error condition, they should be cataloged somewhere. Then you just need to exchange error codes between client and server and do the localization on the client based on the error code.
I am currently trying to figure out a way on how I can possibly save the compile time and runtime errors (in database tables) that the project/solution/website in my visual studio solution explorer could possibly throw.
Thanks for the help in advance.
Update: For now I would want to log the errors only for C# language.
I am desperately looking for a way or solution to implement this...any help will be deeply appreciated...
NiK.
Compile time errors are saved in a html buildlog, check your output window for the link. Shouldn't be too hard to put in a database. A piece of software that does use this information is CruiseControl.Net, so you could probably learn from looking at their code.
For runtime errors, it's impossible to answer. First of all, it's unclear what you are asking. By "runtime errors", do you mean exception eg divide by zero? Second, this is also very different between different languages supported in VS, eg .NET languages and straight C++.
Update: Since you're on the .NET platform, I suggest you either wrap your main function with a try/catch block that catches all thrown errors, and just log all the information you can get from that error to your database (eg stack trace, Exception kind, perhaps a minidump). This, of course, will not work with errors that are caught or swallowed. In case you would also want to log those (for whatever reason), you would have to do some more clever source transformations, for example by using reflection. An example would be to add logging to the constructor of the base class Exception.
My suggestion would be to look into developing an extension to visual studio, similar to Jetbrain's Resharper. Visual Studio exposes a rich api for interacting with the IDE itself. If you are using command line builds outside of visual studio, you may need to pipe the output to a file and parse it.
Here's a few links to get you started on developing an extension/add-in:
http://msdn.microsoft.com/en-us/library/dd885119.aspx
http://msdn.microsoft.com/en-us/vstudio/bb968855
And here's a link for a video for integrating with the error list:
http://msdn.microsoft.com/en-us/vstudio/cc563922
Runtime errors may be easier since there is an appdomain exception event that you can handle. You can wire up a handler to this event and log the exception.
http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx
For handled exceptions, there are a couple of techniques. Microsoft has an exception handling block that can be used, or you could create a custom exception type that you use throughout the application.
Sound like you want this for a website. You can create a Global class (Global.asax.vb) and then handle the error in the Application_Error event. This is where you deal with any unhandled exceptions (vb example is what I have):
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
' Fires when an error occurs
Dim appException As System.Exception = Server.GetLastError()
Dim tempException As System.Exception = Nothing
If appException Is Nothing Then
Return
End If
tempException = appException.InnerException
tempException will hold the unhandled exception and you can store it in a database, or email it to someone. Your choice.
You can do something very similar in winform apps by handling the _unhandledException event in the Application events.
Visual Studio Project files are MSBuild files which can contain custom compilation steps. Maybe it's possible to replace the compilation step with a custom step which calls the CSharp compiler and logs the error.
If you give us a bit more information on what you want to use it for, maybe we can provide alternative solutions. For example do you need to log the errors from inside visual studio or is it enough to have an external tool log these errors?
Only the C++ compiler does a buildlog. C# does not. You will have to either go the plugin/extension route (in which case, use Dave Ferguson's suggestions to get started) or you can use the command line to compile (csc.exe) and pipe the output to a file (csc.exe /options >> log.txt), and parse it.
I'm executing IronPython in my application. A script produces an UnboundNameException with the message "name 'source' is not defined". Because the script is correct in my opinion I would need more error information, but I'm not able to get them from the exception. The exception itself seems not to contain any information about line number of the source of the exception or something like this.
I searched on Google, but all available information seems to be outdated. The Data dictionary of my exception is empty which means that Data["PythonExceptionInfo"] does not exist.
The file version of my IronPython assembly is 2.0.20209.0
Any hint how to get more error details?
cheers,
Achim
See this question: Getting traceback information from IronPython exceptions
That will tell you how you can format the exception (and in a general way that's not going to become outdated). That should work w/ IronPython 2.0 - 2.7.