Applications created by VB Migration Partner internally use reflection, therefore it is necessary that they run under a security context that permits reflection operations. If the application isn’t launched from a local hard-disk, you might need to relax the default .NET security policies.

Additionally, a converted .NET application might be prevented from running correctly if the security policy it is subject to prevents calls to unmanaged code. The following objects are implemented as wrappers of COM components or ActiveX objects and therefore require full trust:

• The following controls (defined in CodeArchitects.VBLibrary.dll) are implemented as wrappers on the corresponding ActiveX control: Winsock, INet, MSComm, MAPISession, MAPIMessages, and ScriptControl. (Notice that all these controls are invisible at runtime.)
• The following controls (defined in CodeArchitects.VBLibraryOcx.dll) are implemented as wrappers on the corresponding ActiveX control: DataGrid, MSHFlexGrid, MSChart, MMControl.

Also, the control support library uses unmanaged code to implement the following features:

• the WhatsThisHelpID property and the ShowWhatsThis method exposed by all controls
• the AppActivate method, if its “wait” argument is True
• the Point method of Form, UserControl, and PictureBox classes
• FileOpen and FileSave common dialogs whose Flags property doesn’t have the cldOFNExplorer flag set
• the Help common dialog, when displaying .chm help files
• StatusBar panels whose style is equal to PanelStyleConstants.sbrIns
• the Animation control
• ACStatus, BatteryFullTime, BatteryLifePercent, BatteryLifeTime, and BatteryStatus properties of the SysInfo control
• the Drive.SerialNumber property (FileSystemObject library)
• the Folder.ShortPath and File.ShortFileName propertyes (FileSystemObject library)

For these members to work correctly, the .NET application must have the permission to call unmanaged code.