Nativer Code kann nicht auf Windows Forms-Objekte zugreifen.

2025-06-20

Ab .NET 5 können Sie nicht mehr über systemeigenen Code auf Windows Forms-Objekte zugreifen.

Änderungsbeschreibung

In früheren .NET-Versionen wurden einige Windows Forms-Typen als sichtbar für die COM-Interoperabilität gekennzeichnet und somit für nativen Code zugänglich. Ab .NET 5 sind keine Windows Forms-APIs für COM-Interop sichtbar oder für nativen Code zugänglich. Die .NET-Runtime unterstützt das Erstellen von benutzerdefinierten Typbibliotheken nicht mehr standardmäßig. Darüber hinaus kann die .NET-Laufzeit nicht von der Typbibliothek für .NET Framework abhängen (was die Beibehaltung der Form von Klassen wie in .NET Framework erfordern würde).

Grund für Änderung

Entfernen von ComVisible(true) aus Enumerationen, die für die Generierung und Suche der Typbibliothek (TLB-Datei) verwendet wurden: Da keine WinForms-TLB von .NET Core bereitgestellt wird, gibt es keinen Grund, dieses Attribut beizubehalten.
Entfernen von ComVisible(true)-Attributen aus AccessibleObject-Klassen: Die Klassen sind nicht CoCreateable (sie besitzen keinen parameterlosen Konstruktor), und das Attribut ist nicht erforderlich, um eine bereits vorhandene Instanz für COM bereitzustellen.
Entfernung von ComVisible(true) aus den Control und Component Klassen: Dies ermöglichte das Hosten von WinForms-Steuerelementen mithilfe von OLE/ActiveX, z. B. in VB6 oder MFC. Dies erfordert jedoch eine TLB für WinForms, die nicht mehr bereitgestellt wird, sowie eine registrierungsbasierte Aktivierung, die auch nicht sofort einsatzbereit wäre. Im Allgemeinen gab es keine Wartung des COM-basierten Hostings von WinForms-Steuerelementen, daher wurde die Unterstützung entfernt, anstatt sie in einem nicht gewarteten Zustand beizubehalten.
Entfernen von ClassInterface Attributen aus Steuerelementen: Wenn das Hosting über OLE/ActiveX nicht unterstützt wird, werden diese Attribute nicht mehr benötigt. Sie werden an anderen Orten aufbewahrt, an denen Objekte weiterhin COM ausgesetzt sind und das Attribut relevant ist.
Entfernung von ComVisible(true) aus EventArgs: Sie wurden wahrscheinlich mit OLE/ActiveX-Hosting verwendet, da dies nicht mehr unterstützt wird. Sie sind auch nicht coCreateable, sodass das Attribut keinen Zweck hat. Außerdem ist das Verfügbarmachen vorhandener Instanzen ohne Angabe einer TLB nicht sinnvoll.
Entfernen von ComVisible(true) aus Delegates: Der Zweck ist unbekannt, aber da das ActiveX-Hosting von WinForms-Steuerelementen nicht mehr unterstützt wird, ist es unwahrscheinlich, dass sie nützlich sind.
Entfernung von ComVisible(true) aus einigen nicht öffentlichen Codeabschnitten: Der einzige potenzielle Nutzer wäre der neue Visual Studio-Designer, aber da keine GUID angegeben ist, ist es unwahrscheinlich, dass er noch benötigt wird.
Entfernen von ComVisible(true) aus einigen beliebigen öffentlichen Designerklassen: Möglicherweise hat der alte Visual Studio-Designer COM-Interop verwendet, um mit diesen Klassen zu kommunizieren. Der alte Designer unterstützt .NET Core jedoch nicht, daher benötigen nur wenige Personen diese als ComVisible.
IWin32Window definiert die gleiche GUID, die in .NET Framework definiert wurde, was gefährliche Folgen hat. Wenn Sie eine Interoperabilität mit .NET Framework benötigen, verwenden Sie ComImport.
Das von WinForms verwaltete IDataObject wurde zu ComVisible gemacht. Dies ist nicht erforderlich, es gibt eine separate ComImport Schnittstellendeklaration für IDataObject COM-Interop. Es ist kontraproduktiv, wenn das verwaltete IDataObjectComVisible ist, da keine TLB bereitgestellt wird und beim Marshalling immer Fehler auftreten. Außerdem wurde die GUID nicht angegeben und unterscheidet sich von .NET Framework. Daher ist es unwahrscheinlich, dass das Entfernen einer nicht dokumentierten IID-Datei die Kunden negativ beeinflusst.
Entfernung von ComVisible(false): Diese werden scheinbar willkürlich platziert und sind redundant, da der Standard darin besteht, Klassen nicht für die COM-Interoperabilität verfügbar zu machen.

Eingeführte Version

.NET 5.0

Empfohlene Aktion

Im folgenden Beispiel wird .NET Framework und .NET Core 3.1 verwendet. In diesem Beispiel wird die .NET Framework-Typbibliothek verwendet, mit der JavaScript über Spiegelung wieder in die Formularunterklasse zurückrufen kann.

[PermissionSet(SecurityAction.Demand, Name="FullTrust")]
[System.Runtime.InteropServices.ComVisibleAttribute(true)]
public class Form1 : Form
{
    private WebBrowser webBrowser1 = new WebBrowser();

    protected override void OnLoad(EventArgs e)
    {
        webBrowser1.AllowWebBrowserDrop = false;
        webBrowser1.IsWebBrowserContextMenuEnabled = false;
        webBrowser1.WebBrowserShortcutsEnabled = false;
        webBrowser1.ObjectForScripting = this;

        webBrowser1.DocumentText =
            "<html><body><button " +
            "onclick=\"window.external.Test('called from script code')\">" +
            "call client code from script code</button>" +
            "</body></html>";
    }

    public void Test(String message)
    {
        MessageBox.Show(message, "client code");
    }
}

Es gibt zwei möglichkeiten, das Beispiel für .NET 5 und höhere Versionen zu verwenden:

Führen Sie ein vom Benutzer deklariertes ObjectForScripting-Objekt ein, das IDispatch unterstützt. Diese Unterstützung wird standardmäßig angewendet, es sei denn, sie wird explizit auf Projektebene geändert.

public class MyScriptObject
{
    private Form1 _form;

    public MyScriptObject(Form1 form)
    {
        _form = form;
    }

    public void Test(string message)
    {
        MessageBox.Show(message, "client code");
    }
}

public partial class Form1 : Form
{
    protected override void OnLoad(EventArgs e)
    {
        ...

        // Works correctly.
        webBrowser1.ObjectForScripting = new MyScriptObject(this);

        ...
    }
}

Deklarieren Sie eine Schnittstelle mit den methoden, die verfügbar gemacht werden sollen.

public interface IForm1
{
    void Test(string message);
}

[ComDefaultInterface(typeof(IForm1))]
public partial class Form1 : Form, IForm1
{
    protected override void OnLoad(EventArgs e)
    {
        ...

        // Works correctly.
        webBrowser1.ObjectForScripting = this;

        ...
    }
}

Betroffene APIs

Alle Windows Forms-APIs.

Freigeben über