exception/Exception clash using mixed dll in VB.NET

[Chris Baldwin]

Hello,

I'm having a problem with a mixed managed/unmanaged DLL. When I
attempt to reference "Exception" in my VB.NET code, it conflicts with
some other "exception" that gets somehow gets into the assembly.

This code reproduces the issue:

#using <System.dll>
// #include <vector> is in stdafx.h
#include "stdafx.h"

namespace ExceptionClash
{
public __gc class Class1
{
public:
System::String* SayHello()
{
return S"Hello";
}
};
}
And then, ExceptionClash. Class1 is used by this VB.NET code:

Imports ExceptionClash

Public Class Test
Public Shared Sub Main()
Dim o As New Class1
Try
Dim s As String
s = o.SayHello()
Console.WriteLi ne(s)
Catch ex As Exception
Console.WriteLi ne(ex.ToString( ))
End Try
End Sub
End Class

The error I get is upon compilation of the VB.NET code:

C:\temp\Excepti onClash\Debug\t est.vb(14) : error BC30392: 'Catch'
cannot catch t
ype 'exception' because it is not 'System.Excepti on' or a class that
inherits fr
om 'System.Excepti on'.

If I view ExceptionClass. dll in ildasm, I see a type "exception" in
the root namespace. This is conflicting with System.Exceptio n in
VB.NET. It seems to only happen when #include <vector> is in
stdafx.h. I am not sure where this other "exception" class is coming
from.

I can work around the issue by not using "Imports ExceptionClash" or
by specifying System.Exceptio n instead of just Exception. But, I'm
looking for some understanding or a resolution as opposed to a
workaround.

Does anyone have any insight into this issue?

Thanks in advance,
Chris

[Ronald Laeremans [MSFT]]

Hi Chris,

Please look at the following reference:
http://support.microsoft.com/default...b;en-us;822330

Thanks.

Ronald Laeremans
Visual C++ team

"Chris Baldwin" <ei******@hotma il.com> wrote in message
news:97******** *************** ***@posting.goo gle.com...

Hello,

I'm having a problem with a mixed managed/unmanaged DLL. When I
attempt to reference "Exception" in my VB.NET code, it conflicts with
some other "exception" that gets somehow gets into the assembly.

This code reproduces the issue:

#using <System.dll>
// #include <vector> is in stdafx.h
#include "stdafx.h"

namespace ExceptionClash
{
public __gc class Class1
{
public:
System::String* SayHello()
{
return S"Hello";
}
};
}
And then, ExceptionClash. Class1 is used by this VB.NET code:

Imports ExceptionClash

Public Class Test
Public Shared Sub Main()
Dim o As New Class1
Try
Dim s As String
s = o.SayHello()
Console.WriteLi ne(s)
Catch ex As Exception
Console.WriteLi ne(ex.ToString( ))
End Try
End Sub
End Class

The error I get is upon compilation of the VB.NET code:

C:\temp\Excepti onClash\Debug\t est.vb(14) : error BC30392: 'Catch'
cannot catch t
ype 'exception' because it is not 'System.Excepti on' or a class that
inherits fr
om 'System.Excepti on'.

If I view ExceptionClass. dll in ildasm, I see a type "exception" in
the root namespace. This is conflicting with System.Exceptio n in
VB.NET. It seems to only happen when #include <vector> is in
stdafx.h. I am not sure where this other "exception" class is coming
from.

I can work around the issue by not using "Imports ExceptionClash" or
by specifying System.Exceptio n instead of just Exception. But, I'm
looking for some understanding or a resolution as opposed to a
workaround.

Does anyone have any insight into this issue?

Thanks in advance,
Chris

[Chris Baldwin]

Ronald,

Thanks for the link. I should've mentioned in my first post that
we're compiling with VS2002. Knowing that, any other tips?

Thanks again,
Chris
"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message news:<Ox******* *******@tk2msft ngp13.phx.gbl>. ..

Hi Chris,

Please look at the following reference:
http://support.microsoft.com/default...b;en-us;822330

Thanks.

Ronald Laeremans
Visual C++ team

"Chris Baldwin" <ei******@hotma il.com> wrote in message
news:97******** *************** ***@posting.goo gle.com...

Hello,

I'm having a problem with a mixed managed/unmanaged DLL. When I
attempt to reference "Exception" in my VB.NET code, it conflicts with
some other "exception" that gets somehow gets into the assembly.

This code reproduces the issue:

#using <System.dll>
// #include <vector> is in stdafx.h
#include "stdafx.h"

namespace ExceptionClash
{
public __gc class Class1
{
public:
System::String* SayHello()
{
return S"Hello";
}
};
}
And then, ExceptionClash. Class1 is used by this VB.NET code:

Imports ExceptionClash

Public Class Test
Public Shared Sub Main()
Dim o As New Class1
Try
Dim s As String
s = o.SayHello()
Console.WriteLi ne(s)
Catch ex As Exception
Console.WriteLi ne(ex.ToString( ))
End Try
End Sub
End Class

The error I get is upon compilation of the VB.NET code:

C:\temp\Excepti onClash\Debug\t est.vb(14) : error BC30392: 'Catch'
cannot catch t
ype 'exception' because it is not 'System.Excepti on' or a class that
inherits fr
om 'System.Excepti on'.

If I view ExceptionClass. dll in ildasm, I see a type "exception" in
the root namespace. This is conflicting with System.Exceptio n in
VB.NET. It seems to only happen when #include <vector> is in
stdafx.h. I am not sure where this other "exception" class is coming
from.

I can work around the issue by not using "Imports ExceptionClash" or
by specifying System.Exceptio n instead of just Exception. But, I'm
looking for some understanding or a resolution as opposed to a
workaround.

Does anyone have any insight into this issue?

Thanks in advance,
Chris

[Ronald Laeremans [MSFT]]

VS 2002 does not have this behavior in the first place (it works as though
you would have specified /d1PrivateNative Types).

Can you sue ILDASM to look at the assembly you created to see exactly what
the definition of the exception object is you have in there?

VS 2002 really is not a great tool for creating MC++ applications. Is there
a specific reason why you have not upgraded to VC 2003 where many
significant issues have been fixed?

Ronald

"Chris Baldwin" <ei******@hotma il.com> wrote in message
news:97******** *************** ***@posting.goo gle.com...

Ronald,

Thanks for the link. I should've mentioned in my first post that
we're compiling with VS2002. Knowing that, any other tips?

Thanks again,
Chris
"Ronald Laeremans [MSFT]" <ro*****@online .microsoft.com> wrote in message
news:<Ox******* *******@tk2msft ngp13.phx.gbl>. ..

Hi Chris,

Please look at the following reference:
http://support.microsoft.com/default...b;en-us;822330

Thanks.

Ronald Laeremans
Visual C++ team

"Chris Baldwin" <ei******@hotma il.com> wrote in message
news:97******** *************** ***@posting.goo gle.com...

> Hello,
>
> I'm having a problem with a mixed managed/unmanaged DLL. When I
> attempt to reference "Exception" in my VB.NET code, it conflicts with
> some other "exception" that gets somehow gets into the assembly.
>
> This code reproduces the issue:
>
> #using <System.dll>
> // #include <vector> is in stdafx.h
> #include "stdafx.h"
>
> namespace ExceptionClash
> {
> public __gc class Class1
> {
> public:
> System::String* SayHello()
> {
> return S"Hello";
> }
> };
> }
>
>
> And then, ExceptionClash. Class1 is used by this VB.NET code:
>
> Imports ExceptionClash
>
> Public Class Test
> Public Shared Sub Main()
> Dim o As New Class1
> Try
> Dim s As String
> s = o.SayHello()
> Console.WriteLi ne(s)
> Catch ex As Exception
> Console.WriteLi ne(ex.ToString( ))
> End Try
> End Sub
> End Class
>
> The error I get is upon compilation of the VB.NET code:
>
> C:\temp\Excepti onClash\Debug\t est.vb(14) : error BC30392: 'Catch'
> cannot catch t
> ype 'exception' because it is not 'System.Excepti on' or a class that
> inherits fr
> om 'System.Excepti on'.
>
> If I view ExceptionClass. dll in ildasm, I see a type "exception" in
> the root namespace. This is conflicting with System.Exceptio n in
> VB.NET. It seems to only happen when #include <vector> is in
> stdafx.h. I am not sure where this other "exception" class is coming
> from.
>
> I can work around the issue by not using "Imports ExceptionClash" or
> by specifying System.Exceptio n instead of just Exception. But, I'm
> looking for some understanding or a resolution as opposed to a
> workaround.
>
> Does anyone have any insight into this issue?
>
> Thanks in advance,
> Chris