Comments by mathias.woelfel (Top 9 by date)

Yes that is what I suspected, too. But how to implement this exeption stack if I don't know which exeptions of which type are thrown? How can I implement try&catch recursively?? I'm a little bit at a loss at the moment..

But shouldn't the outer exeption handler catch all inner exceptions anyway? I even tried to nest several try/catch blocks arround the object instantiation what didn't help either. It seems like the FileNotFoundException is not thrown within my try block but anywhere else. Is that possible?

Coming back to your idea with the recursive catching of all inner exceptions: How would you implement this solution? Is there a possibility to find out if there are unhandled exceptions left? Or is there an exception stack which I can read out?

Thank you for this detailed explanation on handling assemblys!
But my problem is another one: As I described my simple check with File::Exists alone works fine. The function returns at the specified point if the dll is not found.
But if I add the instantiation of the object to the function it throws the exception even if this part of the code is not executed.

Yes, I tried that before!

But although the error message while crashing tells me there is an System.IO.FileNotFoundException I can't catch it with
catch(System::IO::FileNotFoundException ^ex)

And even if I try to catch every exeption with
catch(...)
I've got the same behaviour like I described above.