問題タブ [strongname]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
10 に答える
22993 参照

.net - .NET アセンブリに署名しないことに何か問題がありますか?

私の同僚の 1 人は、アセンブリに署名することに非常に熱心です。彼は文字通り何にでも署名しようとします。署名されていない Microsoft のアセンブリを使用する場合でも、彼はソース コードを取得して署名し、代わりに他の開発者に彼のコピーを使用するように依頼します。

アセンブリに署名することの背後にある基本的な考え方を理解できます。つまり、特定のアセンブリが危険なハッカーによって危険にさらされないようにすることです。そのため、ソフトウェア開発会社の場合、顧客に .NET ライブラリをリリースする前に、アセンブリに署名する必要があります。

ただし、ここでは主に自分で使用するための Web アプリケーションを開発しており、使用するすべてのアセンブリに署名する意味がわかりません。

ここで何か不足していますか?

0 投票する
4 に答える
2206 参照

.net - この.NETアセンブリ署名のことを理解できないようです

わかりました、私はすでにこれを読んだので、私はばかでなければなりません: http://www.csharp411.com/net-assembly-faq-part-3-strong-names-and-signing/

そして、私はまだそれを理解していません...

プロジェクトのプロパティを開いて [署名] タブに移動し、[アセンブリに署名する] をオンにして、パスワードを使用して新しいアセンブリを生成するとします。公開鍵と秘密鍵の両方を含む .pfx 拡張子を持つ厳密な名前の鍵ファイルが作成され、VS はコンパイル時にアセンブリにデジタル署名しますよね?

秘密鍵はどうですか?非公開にして、開発者である私だけがそれを持っているべきではありませんか? アセンブリは公開キーのみで署名されるべきではありませんか?

誰かが私にこれを説明できますか? 基本的に、私は自分のプロジェクトのアセンブリに署名し、アセンブリが本当に私によって開発されたものであるかどうかをユーザーが確認できるようにしたいと考えています.

0 投票する
1 に答える
2039 参照

.net - 製品で使用するすべてのアセンブリに厳密な名前を付けていますか?

約 10 個以上のアセンブリを含む製品があります。以前は、アセンブリに明確な名前を付けずに出荷していました。しかし、厳密な名前付けについて読んだ後、アセンブリに厳密な名前を付けるのは賢明な考えだと思います。知りたかったのは、プログラムで使用されるすべてのアセンブリに厳密な名前を付けるベスト プラクティスですか?

何かご意見は?

0 投票する
2 に答える
151 参照

.net - .net アセンブリのメタデータまたはヘッダーにデータを保持することは可能ですか?

ストロングネームと同じようにカスタムアセンブリ署名メカニズムを実装したいのですが、署名情報をアセンブリメタデータに書き込むプログラムを開発し、内部読み取りのアセンブリで署名の検証が正しいです。これを行うことは可能ですか?

0 投票する
1 に答える
78 参照

c# - 内部を見るデザイナー?

ここに署名済みのアセンブリがあります。そのうちの 1 つで、リソースに写真があります。もう 1 つはそれ自体を使用することが許可されているため、他のアセンブリは画像を参照でき、すべて正常に動作します。


VS2008 のフォーム デザイナーでない場合のみ。画像が表示されません。(コンパイル時にリンクされているので、大丈夫かもしれません。考えるでしょう!!! )


internalしかし、画像が からに手動で変更された場合、これらの画像は表示されpublicます。リソース クラスは内部のままです。その後、動作します。(同じ名前空間だからです。) リソース クラスは部分的ではありません。部分的は同じアセンブリ内でのみ機能するため、役に立たないからです。


問題は、これらのリソースは何らかの理由で内部のものであり、署名されていないアセンブリからそれらを再利用したくないことです。さらに、チーム外の他の人がそうするのを望んでいません。

助言がありますか?

事前にThx

0 投票する
3 に答える
2278 参照

c# - 厳密な名前を持つ C# プラグイン アーキテクチャ: 誤解

Active Directory と通信してユーザー情報を取得するサーバー実行可能ファイルがあります。AD に加えて、この exe を使用すると、顧客は独自のプラグインを記述して、カスタム ユーザー ディレクトリと通信できます。

この実行可能ファイルには厳密な名前が付けられています。

次の記述は正しいですか。

厳密な名前のアセンブリが別のアセンブリを読み込むには、読み込まれたアセンブリも同じキーで署名されている必要があります。

アセンブリが厳密に署名されていない場合、次のコードは null を返します。アセンブリが適切に署名されていないことを示すエラーはありません。アセンブリに署名すると、IService のインスタンスが得られることに注意してください。これにより、読み込まれたアセンブリは強力に署名されている必要があると私は信じています。

つまり、強力に署名されたアセンブリがあり、アセンブリ プラグインをサポートしている場合、それらも署名する必要があるということですか?プラグインの作成者は同じキーで署名する必要があります。それは正しく聞こえません。

最後に、IService インターフェイスを実装するだけでなく、別のアセンブリを参照するアセンブリも参照するアセンブリがあり、それぞれが異なるキーで署名されているとします。ロードしようとするとどうなりますか? それらはすべて同じ鍵で署名する必要がありますか?

0 投票する
2 に答える
1108 参照

visual-studio - 自動的に強力な名前を付ける COM Interop ラッパー

いくつかの COM ライブラリを参照している Visual Studio 2005 の C# プロジェクトがあります。ビルドすると、次のようなエラーがスローされます。

参照されたアセンブリ 'assemblyName' には厳密な名前がありません。

以前は Visual Studio 2003 で COM アセンブリを参照していましたが、Interop ラッパーに自動的に署名していました。私がしなければならなかったのは、設定「Wrapper Assembly Key File」を設定することだけでした。

Visual Studio 2005 で同様の設定を探してみましたが、見つかりませんでした。したがって、Visual Studio 2005 で COM Interops に厳密な名前を付け、上記のエラーを取り除く同等の方法があるかどうか疑問に思っていました。

0 投票する
7 に答える
7568 参照

.net - アセンブリの厳密な名前を使用するリソース URI を使用するように WPF を強制する方法は? ああ!

わかりました、これは本当にイライラします。XAML リソースをロードするために WPF によって生成されたコードが厳密な名前を使用していないように見えるため、WPF アセンブリのサイド バイ サイド バージョンをサポートする必要があるシナリオでは問題になる可能性があることに以前気付きました。

これは事実であることが判明し、現在問題を引き起こしています-バージョン番号(アセンブリバージョン)のみが異なるプラグインのサイドバイサイドインストールをサポートするプラグインシステムがあります。厳密に名前が付けられていて、異なる公開/秘密キーまたは異なるアセンブリ バージョン番号を持っている場合、同じ DLL ファイル名を持っていても、アセンブリは異なる ID を持つと判断されるため、これはもちろん .NET でサポートできます。

ここで、Visual Studio によってウィンドウとユーザー コントロール用に生成されたコードを見ると、自動生成されたファイルに次のように表示されます。

リソース ロケーターが作成される行に注意してください。これは、厳密な名前または xaml リソースを含むアセンブリのバージョンを指定しない相対 URI を使用しています。

LoadComponent が呼び出し元のアセンブリの ID を確認し、その公開キーとバージョンの詳細を使用するか、「this」パラメーターの型を含むアセンブリの ID を確認する可能性があると思いました。

これは当てはまらないようです。バージョン番号が異なる (ただしファイル名は同じ) 2 つのアセンブリがある場合、「リソース X が見つかりません」というメッセージとともに IOException が発生する可能性があります (上記の例では、「リソース 'views/servicepanelui が見つかりません」 .xaml'.

さらに悪いことに、これは、ファイル名が同じで公開/秘密キーが異なる、つまり異なる発行元からのアセンブリでも、このエラーが発生することを意味すると確信しています。

それで、誰もこれを回避する方法を知っていますか?WPF の厳密な名前に準拠する方法。

私に関する限り、これは WPF のバグです。これを回避するためだけに Appdomain 分離を使用する必要はありません。

0 投票する
1 に答える
3192 参照

signing - アセンブリへの署名中の暗号化の失敗'.dll'–'プロバイダーの不正なバージョン'

有名なプロバイダーからauthenticode証明書を購入しました。

今、私はアセンブリに強い名前を付け、後でデジタル署名したいと思います。

これは私がこれまでに行ったことです:

  • sn.exe -p keypair.pfx key.snkを実行して、pfxから公開鍵を抽出しました
  • プロジェクトプロパティの[署名]タブで[アセンブリに署名する]チェックボックスと[署名のみを遅らせる]チェックボックスの両方をオンにしました
  • 署名するキーファイルとしてkey.snkを提供
  • sn.exe-tPkey.snkを実行して公開鍵トークンを抽出しました
  • sn -Vr *を実行して、devboxで厳密な名前の検証を無効にしました。

チームビルドで遅延署名を無効にし、そこにkeypair.pfxファイルを提供するという考え方です。このようにして、セキュリティ上の理由から開発ボックスに秘密鍵を提供せずに、アクセスが制限されているチームビルドサーバーでアセンブリに完全に署名できます。

ただし、アセンブリをローカルでビルドしようとすると、次のエラーが発生します。

アセンブリ'.dll'の署名中に暗号化エラーが発生しました–'プロバイダーのバージョンが正しくありません'

誰かがこれに対する解決策を持っていますか?

0 投票する
3 に答える
836 参照

c# - プライベート アセンブリに厳密な名前を付ける必要はありません。

アセンブリを共有する多数のアプリケーションを作成しています。メモリやディスク容量は問題にならないため、共有アセンブリを各アプリのローカル フォルダーに複製して、プライベート アセンブリを使用します。これにより、それらを GAC に配置することによって引き起こされる問題が回避されます。厳密な名前は、GAC でアセンブリを共有する場合に必要とされる非常に優れたものであると聞いています。

プライベート アセンブリに厳密な名前を使用する正当な理由はありますか?

ところで:これはアセンブリに関する優れたリファレンスです:リンクテキスト