Överväganden när du är värd för en ActiveX-kontroll i ett Windows-formulär
Även om Windows Forms har optimerats för att vara värd för Windows Forms-kontroller kan du fortfarande använda ActiveX-kontroller. Tänk på följande när du planerar ett program som använder ActiveX-kontroller:
Security Common Language Runtime har förbättrats när det gäller kodåtkomstsäkerhet. Program med Windows Forms kan köras i en fullständigt betrodd miljö utan problem och i en halvbetrott miljö med de flesta tillgängliga funktioner. Windows Forms-kontroller kan hanteras i en webbläsare utan komplikationer. ActiveX-kontroller i Windows Forms kan dock inte dra nytta av dessa säkerhetsförbättringar. Om du kör en ActiveX-kontroll krävs ohanterad kodbehörighet, som anges med egenskapen SecurityPermissionAttribute.UnmanagedCode. Mer information om säkerhet och ohanterad kodbehörighet finns i SecurityPermissionAttribute.
Total ägandekostnad ActiveX-kontroller som läggs till i ett Windows-formulär distribueras med det Windows-formuläret i sin helhet, vilket kan avsevärt öka storleken på de filer som skapats. Dessutom kräver användning av ActiveX-kontroller i Windows Forms att du skriver till registret. Detta är mer invasivt för en användares dator än Windows Forms-kontroller, vilket inte kräver detta.
Notera
När du arbetar med en ActiveX-kontroll måste du använda en COM-interop-omslutning. Mer information finns i COM-samverkan i Visual Basic och Visual C#.
Not
Om namnet på en medlem i ActiveX-kontrollen matchar ett namn som definierats i .NET Framework prefixar ActiveX-kontrollimportören medlemsnamnet med Ctl- när den skapar den AxHost härledda klassen. Om din ActiveX-kontroll till exempel har en medlem med namnet Layoutbyter den namn till CtlLayout i AxHost-härledd klass eftersom händelsen Layout är definierad i .NET Framework.
Se även
.NET Desktop feedback