私はC＃用のライブラリを作成しています。ライブラリがC＃プロジェクトで使用されている場合にメソッド/フィールドのみを使用できるかどうかと、Visual Basicのような別の.NET言語で使用されている場合はメソッドにアクセスできないのだろうかと思います。その理由は、安全でないコードにしか役に立たないいくつかの関数/フィールドがあり、目的を果たせないVisual Basicのために利用できるならば、ちょっとばかげているからです。条件コードは言語に基づいていますか？
利用されている言語によっては、特定のクラス/メソッド/フィールドしか使用できないのですか？そうでなければ、ダウンロード用に2つの別々のアセンブリ（C＃用とVB.Net用）を簡単に作成できます。あるいは、私は単純に余分なメソッドを含めることができます（しかし、私はポインタと安全でないコードに慣れていない人たちと混乱しないようにしたいと思います。本当に問題ではありません！）。
ありがとうございます！
利用されている言語によっては、特定のクラス/メソッド/フィールドしか使用できませんか？
号
私は、ポインタや危険なコードに慣れていない人たちとの混同を防ぐためにだけ危険な方法をいじり、誤って愚かな何かをすることからユーザーを維持したいと思います。
抽象化を使用します。インターフェイス/ベースクラスを持つアセンブリを作成し、一部のコンシューマにアセンブリを安全実装と他のコンシューマとともにベースアセンブリと一緒に提供します。
また、内部メソッドを持つアセンブリを1つ使用し、どの「高度な」アセンブリがそれを消費するかを知っている場合は、InternalsVisibleToAttributeを使用できます。
安全でないコンテキストが別の.NET言語のアセンブリを使用することとどのように関係しているかわかりません。好奇心の外に、私は何かを逃していますか（非常に可能です...）？ –
尋ねられたことをする方法はありません。私は代替案を提供しました - クライアントがどれだけ信頼されているかに依存して、異なるクライアントに異なるアセンブリを提供します（APIを減らしたもの）。 –
ああ、私はそれを実現する。私が求めていることは、安全ではないコンテキストが、他の.NET言語でアセンブリを使用できないようにしてしまうことです（OPはそうすると思います）。 –
私が知っている限り、皆さんがあなたのものを呼び出すアセンブリの言語を決定する方法はありません。誰もがILととにかく（あるいはコンパイルされた命令ですが何でも）話しているからです。
この場合、条件に基づいて2つの異なるバージョンのアセンブリをコンパイルし、使用する言語に応じてユーザーに提供することをお勧めします。または、すべてのコードを含めるだけで、VBユーザーにいくつかの機能にアクセスしないように指示することもできます。
私はあなたがここで何をしているのかが分からないことを認めなければなりません。発信者には安全ではないものがあります。いくつかIntPtrのものか何か？
IntPtrは良いアイデアです。 – Alex
安全でないコードはCLSに準拠していないため、VB.Netから呼び出すことはできません。私はF＃について考えていません。だからあなたは管理されたC++の人々があなたのポインタを使用するのを防ぐだけです。これは少し冗長なようです。あなたの目標は何ですか？ – IanNorton
インターフェイス。インタフェース。インタフェース。 ;-) –