In a BizTalk mapping, I use a scripting functoid from an external assembly. The assembly reference is added. When the mapping is used, however, it causes the following error:
'ScriptNS0:DoSomething()' has failed.
Now, this could mean any number of things that's wrong about this scripting functoid. However, even when a try-catch block is placed around the entirety of the C# code and the catch throws a custom exception, a proper new deploy yields the very same error and not the newly added custom one.
This would suggest that the mapping has been started and that something causes an error as soon as it hits the scripting functoid, but without actually performing even the slightest action within the function. When looking at the XSLT of the map, it seemed perfectly fine. The reference to the external assembly has been checked over and over again (and references of this external assembly as well). Everything looks fine and very much like many other mappings I've seen, yet still the outcome is the error above.
I realise this is a rather vague question, but does anyone have a clue what's going on here?
You'll have to test this out in Visual Studio. A few things to keep in mind:
It's very possible that your actual data is causing an exception (it's an edge or corner case that you're not testing for in your console application).
Throwing exceptions in external assemblies doesn't always translate well in an XSLT map, particularly when you do it on a Port. IIRC it's handled slightly more gracefully in an orchestration.
If you can't reproduce this in Visual Studio testing or a unit test, you should be able to attach the Visual Studio debugger to the appropriate BtsNtSvc.exe or BtsNtSvc64.exe (or w3wp.exe if it's running in IIS/isolated host). Set a breakpoint on the entrance to your custom function, step through, see what's going on. If you're only able to reproduce it in a non-dev environment, see if you can set up remote debugging - but you may be better off enhancing the logging on the functoid in that case and redeploying if possible.
In general, I always try to do the following in custom functoid scripts:
Avoid throwing exceptions - use methods like TryParse rather than Parse, and on failure to parse return an error string or an empty string or the original string (depending on requirements/tolerance of destination system) rather than throwing an exception. If you do throw an exception, it's unlikely to be handled gracefully and unlikely that the exception type or text will make it back to a user/administrator.
Do error logging in these scenarios instead - generally using the Windows Event Log (System.Diagnostics.EventLog.WriteEntry). Make sure to use a properly registered event source, ideally one that matches your application name and is registered by your installation process, but at least one that exists on the computer to avoid throwing another nonsensical exception! This will allow developers/admins faster insight into what's going on next time.
Related
Relatively new to working with .net but learning a lot while working with a developer at work who at times can be stubborn. Recently the asp.net web form we are developing has periodically started crashing such that every time a link is clicked that retrieves an object (an in process form that the user had previously filled out) the user gets the following application error: "Sequence contains more than one element."
All the sources I looked at online suggested that this was an InvalidOperationException thrown by the Single method and could be avoided by (a) eliminating the source of duplicate elements or (b) using the First method instead of the Single method.
The developer told me that I had no idea what I was talking about and that this was a caching error that could only be solved via an IIS reset.
Since this has been happening periodically I'm a bit concerned that doing the IIS reset doesn't address the underlying issue that creates the exception. Any one have any ideas? Is my developer right to say that an IIS reset is the best way to address this?
Thanks!
According to me your developer might have used LINQ. If he used single() or SingleOrDefault() or First() , tell him to replace those method with FirstorDefault() method.
We were getting lots of unhandled null reference exceptions in our application as below.
System.Web.HttpUnhandledException: Exception of type
'System.Web.HttpUnhandledException' was thrown. --->
System.NullReferenceException: Object reference not set to an instance
of an object. at
To get the exact line numbers in the error logs we deployed PDB files in the production environment with PDB only option enabled in release mode.
Now we are getting the line numbers error description but the lines numbers are always pointing to finally block where this is no possibility for the error to occur.
In the Project properties when give the build in release mode the Optimize code will be checked, we found that due to this option the line numbers are incorrect.
Now we are planning to give a deployment in production with this option unchecked so that we will get the correct line numbers. Wanted to check if this will have any impact to the performance of the application if we deploy with this option unchecked to production environment.
Please let me know incase if you have tried this or has come across such scenarios.
Yes, it certainly may have impact on performance, that's what the option is there for.
Basically, you have two options:
Check optimize. This way, your code will be easier to debug, but it may be less efficient.
Don't check optimize. This way, your code will be most likely more efficient, but also harder to debug.
The difference is because if you turn optimize on, the compiler will perform more optimizations, which may transform your code so that line numbers are not accurate, you can't get the value of local variables, etc.
A lot of time can pass between the moment a stack trace is generated and the moment the stack trace is thoroughly investigated. During that time, a lot can happen to the file in question, sometimes obscuring the original error. The error might have been fixed in the meantime (overlapping bugs).
Is it possible to get Stacktraces that show the offending file at the time of the error?
Not elegantly, and you normally don't want the user browsing through code that's throwing unexpected exceptions anyway (open door to an attacker).
Usually, what happens in a dev shop is that the user reports an error, stack trace, and the build it occurred on. As a tester, you can grab that build from your archives (you ARE keeping an archive of all supported releases somewhere handy, RIGHT?), install, run, and try to reproduce the error, working with the user to provide additional info as necessary. I've seen very few bugs that couldn't be reproduced EVENTUALLY, even if it required running the program against a backup of the user's production database to do it.
As a developer, you can download that build's source code from your version control repository (you ARE using version control, RIGHT?), and examine the lines in the stack trace to try to discover the problem by inspection, and/or build and run it to reproduce the error. Then, you go back to the latest source version, build, and run the same steps (a UI automation system can help out here), and if you don't get the error, someone else already found and fixed it. If you still get the error, you also got an updated stack trace with lines that match the current build, allowing you to set your breakpoints and step through.
What KeithS said, plus there are ways to capture more helpful state information at the time of the Exception using the Exception.Data property. See http://blog.abodit.com/2010/03/using-exception-data-to-add-additional-information-to-an-exception/
While KeithS' answer as pretty much correct, it can be easier and more elegant than you think. If you can collect a dumpfile (instead of just a stack trace), you can use a Symbol Server and Source Server in combination with your debugger to automatically pull your correct-version code from source control.
For example: if you enable PDB output and source-server integration in MSBuild, and upload the resulting PDBs to a symbol server, Visual Studio can automatically load the correct source control from a TFS or SourceSafe repository based on the information in a minidump.
On my work computer, debugging in Visual Studio 2008 (SP1) seems to work somewhat different from what I'm used to. I have two problems that might or might not be related.
First problem:
When I'm running a web application in debug mode, and an unhandled exception occurs, I get a Yellow Screen of Death immediately. Normally my code just breaks at the line throwing the exception, allowing me to inspect the state of the program.
For some reason, the only way I can do that on my work PC is to set a breakpoint on the line that threw the exception, and repeat what I did. It's been annoying me for a couple of days now, but I have no idea what could cause this. Any ideas?
Second problem
The WCF webservices used in the site I'm debugging behave a little odd when it comes to debugging as well. Most of the time, setting a breakpoint in the service won't have any effect when it executes that code. At first, I figured I had to attach to the wcfhost process, but that isn't it. When I put a breakpoint on the line where it calls the service, and use F11 to step into the method call, I do end up in the service's code and I can debug all I want.
Why would stepping into work, while breakpoints get ignored? Is there a way to change this behavior?
For the 1st problem:
In Visual Studio go to Debug/Exceptions
You should see three columns in the list: "Name" (type of exceptions), "Thrown", "User-handled"
In the "User-handled" column you have to activate the checkbox for "Common Language Runtime Exceptions".
Note, if you shouldn't see the "User-handled" column, go to Tools/Options, then click on "Debugging" in the tree and on the list activate "Enable Just My Code (Managed only)". Then the column "User-handled" should be visible in the other dialog and you can activate the according checkbox.
For the 2nd problem:
It seems to me as if I have experienced a similar problem. I guess you have to set the breakpoint there, because the WCF service runs on a separate "webserver" (your local VS webserver). Therefore it isn't like a normal method call within your same application and therefore you have to set the breakpoint on the WCF method that gets called. I always did it this way and it worked perfectly for me.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.