Why do server errors occur on running a solution, even if the solution is building successfully?
Compile time versus run-time errors. See this stackoverflow thread for the difference between these two.
From wikipedia:
Thus, for example, a "run-time error" is detected only during the execution of the program, whereas a "compile-time error" is detected by the compiler before the program is started.
It's impossible for the compiler to catch all errors beforehand: see the 'halting problem'.
There are several possibilities:
Difference in run-time vs. compile-time environments (version of .NET, version of IIS, system-level web.config or machine.config or applicationHost.config, etc)
Run-time errors vs. compile-time errors
Different security environment / permissions
Different database connection string requirements
Using IIS vs. Cassini
If you have dynamic references (eg. if you're using NHibernate, for example), it's possible that there are references to an assembly that's not present. These kind of references cannot be picked up by the compiler. It's only one of many possible situations where you'll get a run-time error that's not logic related.
As Q8-coder said, what is the error? Impossible to give solutions without knowing what the error is.
Related
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.
The linker for an iOS simulator target I have is reporting the following warning:
ld: warning: too many personality routines for compact unwind to encode
No line number is given, nor anything else that is actionable. Googling turned up some Apple open source code, but I'm not groking it.
What does it mean and what can I do to address it?
I found some information in the C++ ABI for Itanium docs that sheds some light on what this means.
The personality routine is the function in the C++ (or other language) runtime library which serves as an interface between the system unwind library and language-specific exception handling semantics.
Extrapolating, this warning indicates that you've got too many kinds of exception handling in the same binary, and at least one of them may fail. Indeed this is exactly what is observed in this question.
Sadly, there's no clear way to fix this, only workarounds. You can suppress the warning, remove code, rewrite code in a different language, disable a language's exception handing and possibly others.
If you have a crash on exception with this warning, i.e. ::terminate() call on every throw, the workaround is to use old dwarf exception-handling tables. Add following flags to Build Settings/Linking/Other Linker Flags:
-Wl,-keep_dwarf_unwind -Wl,-no_compact_unwind
You can try silencing the warning with -Wl,-no_compact_unwind for the Other Linker Flags setting. I think it's harmless.
I bumped into this issue as well when trying to run on the iOS simulator while my code was running correctly on the device. In my case, it was not a warning but a linker error.
Luckily, i remembered that I added two flags for luajit to run correctly following the instructions of this page under the section Embedding LuaJIT:
-pagezero_size 10000 -image_base 100000000
My guess is that the image_base address is simply out of bounds on the host CPU.
Anyway, removing these settings made it work in my configuration.
So go to your project's settings and look for any hard wired values of this kind if not the same.
Hope this helps,
M
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.
In my asp.net application I am calling one com component method using Interop dll. This is working fine in normal condition but In production sometimes its throwing below exception
System.Runtime.InteropServices.COMException (0x80010105): The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))
I am suspecting that this is happening when large number of users are accessing same page simultaneously.
Is somebody know solution or steps to debug this issue.
I have another question. while searching on internet I came across this aspcompact attribute and MTA vs STA thread model related to com components . Is this aspcompact attribute is applicable in case of interop dll(Runtime callable wrappers). Will adding this attribute will solve my problem?
RPC_E_SERVERFAULT means that the out-of-process COM server threw a structured (Win32)exception, which could be all sorts of things, such as an Access Violation, Divide by Zero, etc. In other words, there's a bug in the COM server's implementation and there's nothing you can do in your calling application to cure this (unless you can find out what the bug is and can design a way to call the COM component which doesn't execute the buggy code).
You need to find whichever of your colleagues is responsible for the COM server, get him/her to use the debugger to capture a crash dump when the exception occurs, then do post-mortem debugging on the dump to diagnose the problem and fix it.
Monitor your site to capture exception when it raise.
Use Debug Diagnostics Tool v1.2
With the generated dump is easier to identify the point of failure.
Also could mean the COM object crashed. Try to rerun the application represented by the COM object by itself and see if it crashes or produces some error.
I had the same problem, but I got it to work by adding a [STAThread] attribute to the Main function.
[STAThread]
static void Main(string[] args)
I'm running Powershell scripts that use the MS Office 2010 Excel COM objects and started receiving this error. The culprit was the latest MS Office patches. Sorry, I can't specify exactly which one caused the error (I uninstalled a bunch at time), but uninstalling one of them solved the issues. The updates were installed on 7/18/2016.
Whats the advantage of pre-compiling an ASP.NET project using aspnet_compiler.exe?
Also, is there a possibility that a the compiled project will have errors after it is being deployed to a remote server? There is an issue raised by the team that maybe if the machine where the project is compiled and the server where the project will be deployed will have different settings, the project will not run or run erroneously. Has anybody encountered this situation?
I see two principle reasons:
Compile time error checking.
Avoiding overhead of compile on first page fit.
The first of these allows more errors to be detected while in development (e.g. typo in property name) rather than getting the yellow screen of death. If the code in question is an error path, it can be hard to ensure test coverage so things can slip through.
This cannot guarantee that there will be no errors in production. Clearly logic errors will not be found at compile time, nor will missing error handling (to name but two huge categories of bugs).
Also it will not prevent missing reference problems due to a missing assembly (present on the development machine but not deployed to production). Thus good practice is still to have a staging environment (this could also be for acceptance testing) which is treated by developers and testers as if it were production --- only access is to deploy a corrected version (no direct fixing) so fixes all start in development (and source control).
Another advantage is protecting your source code if you have to deploy to an untrusted environment (e.g. shared hosting), as you only deploy binaries which make it much harder for a third party to do any reverse-engineering than if you have all your .cs files up there.
You won't see any cross-platform issues just from performing the compilation. Check out this answer which explains how .NET runs on different architectures.