Ich denke an die Zeichen # @! In einigen COM-Schnittstellen generiert unser System. Die COM-Typbibliothek wird auch nach .NET exportiert. Werden diese Charaktere mir später Probleme bereiten?
Ich habe es heute fast den ganzen Tag getestet und es scheint alles in Ordnung zu sein. Unser System funktioniert weiterhin wie immer.
Der Grund, warum ich vorsichtig bin, ist, dass diese Zeichen in MIDL illegal sind, die C-Syntax für Typnamen verwendet. Aber wir verwenden MIDL nicht - wir bauen unsere Typbibliotheken mit ICreateTypeInfo und ICreateTypeLib. Sieht so aus, als wäre das nur eine MIDL-Einschränkung, und COM und .NET sind mit den nicht alphanumerischen Zeichen zufrieden. Aber vielleicht gibt es etwas, das ich nicht kenne ...
Das habe ich gefunden.
Ich denke, es ist keine Frage, dass die Namen auf der binären Ebene in COM legal sind, da der Name einer COM-Schnittstelle ihre IID ist und der Textname nur Dokumentation ist.
Auf der .NET-Seite ist die Spezifikation der Common Language Infrastructure (ECMA-335, Ссылка .) Ich frage mich, ob .NET oder Mono ihre eigenen Einschränkungen hinzufügen - um so die Interoperabilität zu reduzieren, aber das ist die reale Welt.
Abschnitt 8.5.1 behandelt gültige Typnamen im Common Type System und sagt einfach, dass Namen mit Codepunkten verglichen werden. Seltsam, dass es nichts über die Zusammensetzung eines Namens sagt, sondern nur wie Namen verglichen werden. Dieser Abschnitt wird von MSDN an Ссылка paraphrasiert, was besagt, dass Die einzigen beiden Einschränkungen sind (1) Typnamen sind "codiert als Zeichenfolgen von Unicode (16-Bit) -Zeichen" und (2) sie dürfen kein eingebettetes 0x0000 enthalten.
Ich habe das Bit über 16-Bit-Unicode zitiert, anstatt es zu paraphrasieren, weil es ungenaue Sprache verwendet. Vermutlich hat der Autor dieser Seite UTF-16 gemeint. In jedem Fall spezifiziert ECMA-335 einen Byte-für-Byte-Vergleich und erwähnt Unicode (bezüglich Typnamen) nicht, und verbietet auch keine eingebetteten Nullen. Vielleicht ist .NET hier vom CTS abgewichen, obwohl ich das bezweifle. Wahrscheinlicher ist, dass der Autor dieser MSDN-Seite über Programmiersprachen nachdachte, als er sie schrieb.
Die Common Language Specification (ebenfalls in ECMA-335 definiert) definiert die Regeln für Bezeichner im Quellcode. Bezeichner sind für meine Frage nicht direkt relevant, da meine internen Typnamen niemals im Quellcode erscheinen, aber ich habe mich gleich damit befasst. Der CLS ist eine Teilmenge des CTS, und daher sind seine Beschränkungen nicht notwendigerweise Teil des breiteren CTS. Laut CLS-Regel 4 müssen die Kennungen den Regeln in Anhang 7 des technischen Berichts 15 des Unicode-Standards 3.0 entsprechen - siehe Ссылка . Auch dieses Dokument ist etwas vage, da es sich auf "andere Buchstaben" und "Konnektorzeichen" bezieht, diese aber nicht definiert. Dies half: Ссылка .
Abschnitt 8.5.1 der ECMA-Spezifikation enthält eine nicht-normative Anmerkung, dass ein CLS-Konsument (wie C # oder der Visual Studio-Browser, nehme ich an) "keine Typen zu konsumieren braucht, die CLS-Regel 4 verletzen." Meine vorgeschlagene Schnittstelle Namen verletzen diese Regel 4. Diese Anmerkung scheint zu implizieren, dass ein gültiger Typ einen Namen haben könnte, der gegen Regel 4 verstößt, und dass ein CLS-Verbraucher entweder den Rogue-Namen akzeptieren oder ihn ignorieren sollte. (Der Browser vom Typ Visual Studio zeigt es ohne Beanstandung an.)
Also sind meine vorgeschlagenen Typnamen im Quellcode generell illegal. Beachten Sie jedoch, dass Abschnitt 10.1 (über Bezeichner im CLS) besagt: "Da ihre Regeln nur für in andere Sprachen exportierte Elemente gelten, können private Mitglieder oder Typen, die nicht aus einer Assembly exportiert werden, beliebige Namen verwenden."
Ich folge, dass es sicher ist, die Zeichen # @ zu verwenden! in meinen Typnamen, solange sie in der Binärdomäne verbleiben und niemals im Quellcode oder außerhalb der Assembly angezeigt werden müssen. Und tatsächlich werden sie nie außerhalb des COM-Servers verwendet.
Ein Wort über Zukunftssicherheit ... Das CTS hat so ziemlich nichts über die Zusammensetzung von Typnamen zu sagen, obwohl es einen Abschnitt namens "Gültige Namen" (Abschnitt 8.5.1) gibt. Sie könnten das in der Zukunft ändern, aber diese breite und liberale Spezifikation hat uns alle dazu eingeladen, das zu tun, was wir wollen. Wenn die CTS-Designer Raum für Veränderung gelassen haben wollten, dann hätten sie sicherlich eine gewisse Vorkehrung eingebaut oder zumindest weniger großzügig.
Es ist interessant, dass Sie anscheinend eine Lücke in der COM-Typ-Benennung gefunden haben. Microsoft beschränkt die Verwendung von Zeichen # @! als IDs in MIDL, aber sie duplizieren diese Einschränkung nicht in den Interfaces ICreateTypeInfo und ICreateTypeLib.
Die Verwendung dieser Zeichen funktioniert heute, also was ist das Risiko?
Nun, Microsoft könnte das als ein sehen Fehler und 'beheben' ICreateTypeInfo, ICreateTypeLib, .Net COM Interop und / oder .Net Typ Benennung Einschränkungen in der nächsten Version.
Sie erstellen und verwenden ein Schnittstelle, die keine hat gültige MIDL-Definition.
Sie verwenden Namen, die das tun wahrscheinlich müssen sich ändern wenn (wann) Sie wechseln von COM zu .Net. Auch wenn Sie nur ein erstellen möchten Adapter in .Net eingeben werden Sie nicht sein kann jeden der "ungültigen" wiederverwenden Namen.
Ist das kompatibel mit Mono und? andere Nicht-Microsoft .Net-kompatibel Technologien?
Es gibt viele bekannt gültige
Namen, die verwendet werden könnten (verwenden Sie
etwas wie ' _at_ ' anstelle von
' @ ', etc.) zu vermeiden
zukünftiges Problem.
Wenn Ihnen das alles egal ist, dann werden Sie wahrscheinlich in Ordnung sein. Aber ich vermute durch die Tatsache, dass Sie diese Frage gestellt haben, auf einer Ebene fühlt es sich nicht richtig für Sie.
Viel Glück.
Tags und Links .net com typename typelibrary