Everything is working fine locally but when i upload i get the error
"exception has been thrown by the target of the invocation" my first
instinct is that this is a permissions issue but i dont have access to
the server and ive been told that all permissions are fine.
Your methodology scares the heck out of me!
Based on the (lack of) information you posted, I can give you some general
principles to identify, diagnose, and prevent such exceptions from
occurring:
1. Murphy is your constant companion. Trust no one, especially yourself.
The worst tester of an application is the developer. Just because you
made it work on your dev machine doesn't mean it has no bugs!
You know what your app should do, and are likely to make it do
just that. You have only worked with it on your development machine.
Your development machine is not a live server, much less one
that is hosted by strangers in another part of the world.
2. Your first step to correcting the problem is to locate the point where
it occurred, which Page, what class, what line of code.
Your instincts are not reliable. Trust no one, especially yourself.
There are hundreds of things that can go wrong in an ASP.Net
application. Guessing, especially based on "instinct" is about the
worst possible way to identify the problem.
Keeping point 1 in mind, expecting things to go wrong, use structured
exception handling (try/catch). At the very least, the page itself
ought to be able to give you some information about what went wrong
when it does. Logging is a good thing, but on a hosted server, the
best you may be able to hope for is a detailed error message on the
page, including a Stack Trace, which is a property of the
Exception class.
Tracing is often helpful in determining the cause of a problem.
Try using that if possible.
3. Once the point of failure is identified, an analysis of what caused
the problem is in order. Exceptions are often passed "up the food
chain," and the cause may not actually be in the line of code that is
identified in an error message (if it is). This is where the stack trace
can come in handy. It will show you the stack of instructions that
the exception bubbled up through. The trace does much the same
thing, but with less accuracy.
4. Different types of Exception classes contain different sorts of
information in them. You can use multiple Catch statements to
catch more specific types of exceptions, and extract more
information about the problem from that information. Some
Exceptions contain InnerExceptions as well. The InnerException
is the real thing, if it is present.
5. Here's where your study of what you're using, and the .Net
Framework SDK can come in handy. You need to identify the
mistake you made. Often, this can only be achieved by a
painfully detailed examination of your code. If you did a good
job of tracking the exception down, this will be easier.
6. Once corrected, and re-tested, expect more to come. After
all, Murphy is your constant companion!
7. An after-action review of your methodology will help you
prevent similar such errors from occurring in the future.
What made you screw up? Did you simply overlook a
possibility? Did you rely too much on your tools to do the
heavy lifting for you? Are you getting enough sleep lately?
8. A measure of paranoia is often a programmer's best friend!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
