Type…End Type blocks typically live inside VB6 modules and classes. When VB Migration Partner converts these blocks into VB.NET Structures, it always attempts to move the Structure outside the module it originally resided in. In very few, special cases this operation causes one or more compilation errors. More specifically, this happens if the UDT block depends on a constant that is defined inside the parent module and that the same constant is declared also in another module.
Let’s make an example to show when this problem can occur. Consider the following VB6 code, located in MyModule.cls:
Public Type TestUDT
FileName As String * MAX_PATH
Public Const MAX_PATH As Integer = 260
The above code is converted to VB.NET as follows:
Public Structure TestUDT
<MarshalAs(UnmanagedType.ByValTStr, SizeConst:=MAX_PATH)> _
Public FileName As VB6FixedString
Public Sub InitializeUDT()
FileName = New VB6FixedString(MAX_PATH)
Friend Module MyModule
Public Const MAX_PATH As Short = 260
Now, let’s further assume that the MAX_PATH constant is defined also in AnotherModule.bas. The problem: the TestUDT structure now lives outside the MyModule block, therefore the reference to the MAX_PATH constant has become ambiguous between MyModule and AnotherModule.
This is a very special case that occurs very rarely. VB Migration Partner doesn’t fix the problem automatically, however it is easy to solve the problem by means of a file-level pragma:
Notice that the last argument limits the effect of the PostProcess pragma to the portion of code that precedes the Module keyword, so that references to the MAX_PATH constant inside the module aren’t affected.
Of course, you can expand the pragma to account for multiple constants, as in this example: