問題タブ [cls-compliant]

私は現在、Albahariの C# 3.0 を一言で言えばpg で読んでいます。241 で、配列のインデックス作成について話しているときに、彼は次のように述べています。

非ゼロベースの配列は CLS (Common Language Specification) に準拠していません

ゼロ以外の配列がCLSに準拠していないということは、正確にはどういう意味ですか? また、コードにどのような影響がありますか?

[アップデート]

本のページへのリンクはこちらです。

たとえば、Visual Basic .net には以前は演算子のオーバーロードがなかったため、通常のメソッドとしても提供されていない場合、型のオーバーロードされた演算子を使用できないことを読みました (operator+ の代わりに追加)。

VB にこの機能があるので、演算子のオーバーロードのみではなく、Add、Subtract などの通常の静的メソッドがある場合、CLSCompliant 属性は気にしますか?

口頭の静的メソッドを使用せずにいくつかの型を作成しましたが、演算子のオーバーロードのみであり、C# コンパイラは気にしませんでした。問題がある場合は、私に警告しますよね？

C# ソリューションのアセンブリ内で [assembly: System.CLSCompliant(true)] をオンにしています。

SharePoint Web サービス用に生成されたコード内でいくつかの警告が表示されます。

CLS に準拠していない方法の 1 つを次に示します。

この警告を削除するにはどうすればよいですか?

ありがとう、キース

コンパイラの警告が表示される理由

識別子 'Logic.DomainObjectBase._isNew' は CLS に準拠していません

次のコードは？

新しいプロジェクトのデータアクセス層としてLINQtoSQLを使用しています。データベーステーブルをデザイナに追加しましたが、すべて問題ありません。

関数でこれらのクラスのいずれかを使用すると、VisualStudioは「タイプxxxxはCLSに準拠していません」または「関数xxxxの戻り型はCLSに準拠していません」と警告します。

これは、LINQ to SQLが生成するクラスの問題ですか？それは重要ですか？これらの警告をどこでも無効にできますか？私のVSエラーリストはこれらの警告で詰まっていて、他のものを見るのが難しくなっています。

編集：

申し訳ありませんが、これらはVB.NETプロジェクトです。:)

誰でも次の動作を説明できますか?

要約すると、Visual Studio 2008 で複数のCLS 準拠ライブラリを作成し、それらが共通の名前空間ルートを共有する場合、別のライブラリを参照するライブラリは、それらを消費しない場合でも、そのライブラリの参照への参照を必要とします。

一言で説明するのはかなり難しいですが、動作を再現する手順は次のとおりです (名前空間に細心の注意を払ってください)。

LibraryA という名前のライブラリを作成し、そのライブラリに単一のクラスを追加します。

[assembly: CLSCompliant(true)]AssemblyInfo.csに追加して、ライブラリが CLS 準拠であることを確認します。

LibraryB という別のライブラリを作成し、LibraryA を参照します。次のクラスを LibraryB に追加します。

と

LibraryB も CLS に準拠していることを確認してください。

Class1InLibraryB は LibraryA の型から派生していますが、Class2InLibraryB は派生していないことに注意してください。

ここで、LibraryC という 3 番目のライブラリを作成し、LibraryB を参照します (LibraryA は参照しません)。次のクラスを追加します。

これでもコンパイルできるはずです。Class1InLibraryC は、LibraryA の型を使用しないLibraryB のクラスから派生していることに注意してください。

Class1InLibraryC は、LibraryB で定義された名前空間階層の一部である名前空間で定義されていることにも注意してください。

これまでのところ、LibraryC には LibraryA への参照がなく、LibraryA の型を使用していないため、ソリューションはコンパイルされます。

LibraryC も CLS に準拠するようになりました。突然、ソリューションがコンパイルされなくなり、次のエラー メッセージが表示されます。

タイプ 'Ploeh.Class1InLibraryA' は、参照されていないアセンブリで定義されています。アセンブリ 'Ploeh、Version=1.0.0.0、Culture=neutral、PublicKeyToken=null' への参照を追加する必要があります。

次のいずれかの方法で、ソリューションを再度コンパイルできます。

• LibraryC から CLS 準拠を削除する
• LibraryA への参照を追加します (必要ありませんが)。
• LibraryC の名前空間を、LibraryB の名前空間階層の一部にならないように変更します (たとえば、Fnaah.Samples.LibraryC に)。
• Class1InLibraryB (つまり、 LibracyC から使用されていないもの) の名前空間を、LibraryC の名前空間階層に含まれないように (たとえば、Ploeh.Samples.LibraryB に) 変更します。

名前空間階層と CLS 準拠の間には奇妙な相互作用があるようです。

この問題は、上記のリストのオプションのいずれかを選択することで解決できますが、この動作の背後にある理由を説明できる人はいますか?

.NET / CLRでのAPIのバージョン管理、特にAPIの変更がクライアントアプリケーションをどのように破壊するか、または破壊しないかについて、できるだけ多くの情報を収集したいと思います。まず、いくつかの用語を定義しましょう。

APIの変更-パブリックメンバーのいずれかを含む、タイプのパブリックに表示される定義の変更。これには、タイプとメンバーの名前の変更、タイプの基本タイプの変更、タイプの実装されたインターフェイスのリストからのインターフェイスの追加/削除、メンバーの追加/削除（オーバーロードを含む）、メンバーの可視性の変更、メソッドとタイプのパラメーターの名前変更、デフォルト値の追加が含まれますメソッドパラメーター、型とメンバーの属性の追加/削除、および型とメンバーの汎用型パラメーターの追加/削除（何か見落としましたか？）。これには、メンバー本体の変更やプライベートメンバーの変更は含まれません（つまり、リフレクションは考慮されません）。

バイナリレベルの中断-APIの変更により、古いバージョンのAPIに対してコンパイルされたクライアントアセンブリが新しいバージョンで読み込まれない可能性があります。例：以前と同じ方法で呼び出すことができる場合でも、メソッドのシグネチャを変更します（つまり、voidでタイプ/パラメーターのデフォルト値のオーバーロードを返します）。

ソースレベルの中断-APIの変更により、古いバージョンのAPIに対してコンパイルするように記述された既存のコードが、新しいバージョンでコンパイルされない可能性があります。ただし、コンパイル済みのクライアントアセンブリは以前と同じように機能します。例：以前は明確であったメソッド呼び出しにあいまいさをもたらす可能性のある新しいオーバーロードを追加します。

ソースレベルの静かなセマンティクスの変更-古いバージョンのAPIに対してコンパイルするように記述された既存のコードが、別のメソッドを呼び出すなどして、そのセマンティクスを静かに変更するAPIの変更。ただし、コードは警告/エラーなしでコンパイルを継続する必要があり、以前にコンパイルされたアセンブリは以前と同じように機能するはずです。例：既存のクラスに新しいインターフェースを実装すると、過負荷の解決中に別の過負荷が選択されます。

最終的な目標は、可能な限り多くの破壊的で静かなセマンティクスAPIの変更をカタログ化し、破壊の正確な影響と、それによって影響を受ける言語と影響を受けない言語を説明することです。後者を拡張するには：一部の変更はすべての言語に普遍的に影響しますが（たとえば、インターフェイスに新しいメンバーを追加すると、任意の言語でのそのインターフェイスの実装が機能しなくなります）、一部の変更では、中断するために非常に特殊な言語セマンティクスが必要になります。これには通常、メソッドのオーバーロードが含まれ、一般に、暗黙的な型変換に関係するものはすべて含まれます。ここでは、CLS準拠の言語（つまり、CLI仕様で定義されている「CLSコンシューマー」のルールに少なくとも準拠している言語）についても、「最小公分母」を定義する方法はないようです。誰かが私をここで間違っていると訂正してくれれば幸いです-ですから、これは言語ごとに行わなければなりません。最も興味深いのは、当然、.NETに付属しているC＃、VB、F＃です。ただし、IronPython、IronRuby、DelphiPrismなどの他のものも関連しています。コーナーケースが多いほど、興味深いものになります。メンバーの削除などはかなり自明ですが、メソッドのオーバーロード、オプション/デフォルトパラメーター、ラムダ型推論、変換演算子などの間の微妙な相互作用は非常に驚くべきものです。時には。

これをキックスタートするためのいくつかの例：

新しいメソッドのオーバーロードを追加する

種類：ソースレベルのブレーク

影響を受ける言語：C＃、VB、F＃

変更前のAPI：

変更後のAPI：

変更前に機能し、変更後に壊れたサンプルクライアントコード：

新しい暗黙の変換演算子のオーバーロードを追加する

種類：ソースレベルのブレーク。

影響を受ける言語：C＃、VB

影響を受けない言語：F＃

変更前のAPI：

変更後のAPI：

変更前に機能し、変更後に壊れたサンプルクライアントコード：

注：F＃は、オーバーロードされた演算子を言語レベルでサポートしていないため、壊れていません。明示的でも暗黙的でもありません。どちらもop_Explicit、op_Implicitメソッドとして直接呼び出す必要があります。

新しいインスタンスメソッドの追加

種類：ソースレベルのクワイエットセマンティクスが変更されます。

影響を受ける言語：C＃、VB

影響を受けない言語：F＃

変更前のAPI：

変更後のAPI：

静かなセマンティクスの変更を受けるサンプルクライアントコード：

ExtensionMethodAttribute注：F＃は、の言語レベルのサポートがなく、静的メソッドとしてCLS拡張メソッドを呼び出す必要があるため、壊れていません。

ソリューションをコンパイルすると、次の警告がいくつか表示されます。

どのタイプが準拠していないかに関するその他の情報は提供されていません。私のプロジェクトでは、コンストラクターで params 配列引数を取るいくつかの属性がありますが、それらはすべて内部的なものであり、CLS 準拠には影響しません。この警告が表示される理由と、表示されるタイプは何ですか?

プロジェクトがあり、それを

プロジェクト内のすべてCLSCompliant(True)のクラスの前に配置する必要がありますか?それとも、すべてデフォルトで CLSCompliant に設定されていますか?