469,917 Members | 1,864 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,917 developers. It's quick & easy.

.NET 2005 [C#/VB] Throwing exceptions in a DLL

balabaster
797 Expert 512MB
Hey all, this might seem somewhat remedial but I'm unable to find any documentation on it - it pertains to throwing exceptions within a DLL.

I've written a DLL that contains a bunch of classes. One of my methods validates the contents of a file and throws any necessary exceptions based on invalid content - I'm using a standard "throw new exception..." call ...the thing is, when my code reaches the line where the exception is thrown, my Visual Studio IDE hangs up on that line instead of the external call to my validate method.

A short conceptual example to demonstrate:

MyDLL content:
Expand|Select|Wrap|Line Numbers
  1. Public Class FileContent
  2. Public Function ValidateFile(ByVal FileName As String) As Boolean
  3.     If Not System.IO.File.Exists(FileName) Then 
  4.      Throw New IOException("File "& FileName & " doesn't exist.")
  5.     End If
  6. End Function
  7. End Class
  8.  
Second project that contains reference to DLL
Expand|Select|Wrap|Line Numbers
  1. Imports MyDLL
  2. Public Module Module1
  3. Sub Main()
  4.     Dim oFC As New FileContent
  5.     oFC.ValidateFile("C:\FileThatDoesntExist.txt")
  6. End Sub
  7. End Module
  8.  
So my IDE is actually pulling up the VB file that contains the DLL content and highlights the line in the ValidateFile instead of just hanging on the oFC.ValidateFile method line where the exception is thrown instead of the IDE hanging on the oFC.ValidateFile line in my calling application.

If someone is using my DLL, I don't want them to have access to my code if their file doesn't validate, I just want them to have access to the any exceptions that are raised...am I expecting too much of VS 2005 or is this possible?
Jan 2 '08 #1
3 1766
Plater
7,872 Expert 4TB
Hmm, I have done this and it worked just fine for me.
Do you have debugging information turned on for you .DLL (it's under the project settings, on what to do durring a debug/release build)
Jan 2 '08 #2
balabaster
797 Expert 512MB
Hmm, I have done this and it worked just fine for me.
Do you have debugging information turned on for you .DLL (it's under the project settings, on what to do durring a debug/release build)
Okay, under my debug settings, I've got "Enable the Visual Studio hosting process" checked and nothing else.

Rereading my original post, I'm wondering if I wasn't clear...

Did it make sense that my VS IDE was actually opening the VB file that is contained in the DLL assembly and highlighting the line:
Expand|Select|Wrap|Line Numbers
  1. Throw New Exception("File "& FileName & " doesn't exist.")
When in fact it should be hanging up in my external application on:
Expand|Select|Wrap|Line Numbers
  1. oFC.Validate("C:\FileThatDoesntExist.txt")
At which point my IDE should highlight the oFC.Validate line in the external application and the error should read: "File C:\FileThatDoesntExist.txt doesn't exist."

Not sure if that came across in my first post so I'm not sure if what you're getting me to do is what I'm actually trying to achieve...
Jan 3 '08 #3
Plater
7,872 Expert 4TB
Ahh, I thought it was the otherway around, that you WANTED to go into the DLL and it wasn't.
Debuging information is available for the DLL, so the IDE can navigate to the source code page.
I am about 90% certain that in an actual deployed situation, the compiler will not be able to enter into the source code because it will not exist.
Jan 4 '08 #4

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

21 posts views Thread by mihai | last post: by
3 posts views Thread by kaloianm | last post: by
15 posts views Thread by Sek | last post: by
11 posts views Thread by sternr | last post: by
4 posts views Thread by Sridhar | last post: by
4 posts views Thread by Jay Dee | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.