問題タブ [cer]

が適用されない限り、誰でも壊れる短いサンプルを作成できますか?[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]

MSDNでこのサンプルを実行したところ、ReliabilityContract 属性をコメントアウトしても壊れません。最後に、常に呼び出されるようです。

フレームワーク 2.0 で実行され、IIS 6 サーバーでホストされている Web asp.net アプリケーションがあり、OS は Windows サーバー 2003 です。Web アプリケーションは、Web サービスによって認証されるクライアント証明書を訴えています。ユーザー「ネットワークサービス」でアプリケーションプールを非個人化しました。

問題は、マシン キー/マイ ストレージに格納されている証明書の秘密キーにアクセスする必要がある場合です。ユーザー Network Service はキーにアクセスできません。

winhttpcertcfg.exe ツールを使用して Network Service ユーザーに権限を付与しましたが、結果は同じです。

ローカル管理者でアプリケーション プールを非個人化すると、結果は正常になります。したがって、問題はユーザーの権限にあると考えています。

誰かが私たちにいくつかの情報を与えることができれば、私たちは感謝しています.

前もって感謝します

ファイル ハンドルをパラメーターとして受け入れるネイティブ メソッドを P/Invokes する Visual Studio 2008 C# .NET 3.5 アプリケーションがあります。もともと、私は FileStream.SafeFileHandle.DangerousGetHandle() を使用してファイル ハンドルを取得していました。しかし、FX COP をオンにした後、CA2001 に関する警告が表示されました。それで、少し調べたところ、「制約付き実行領域」を発見しました。これは私にとって新しいことであり、それに関する多くの情報を見たことがありません。私は、より経験豊富な誰かが見て、これを正しく行ったことを確認できることを望んでいました.

ありがとう、ポールH

テストに自己署名証明書を使用していますが、証明書の検証をテストするために証明書失効リストを生成するにはどうすればよいですか？JDKのkeytoolはそのような機能を提供しましたか？

ありがとう！

どうやら、制約付き実行領域の保証はイテレーターには適用されません（おそらく、それらがどのように実装されているかなどが原因です）が、これはバグですか、それとも設計によるものですか？[以下の例を参照してください。]

つまり、イテレータで使用されるCERのルールは何ですか？

（コードは主にここから盗まれました。）

制約付きの実行領域を理解するために、制約付きの実行領域とその他の正誤表 [Brian Grunkemeyer]を読んでいますが、次のサンプルを理解するのに問題があります。

私の理解では、tryブロックは制約されておらず、finally ブロックと catch ブロックのみが制約されています。これは、tryブロック中に非同期例外 (ThreadAbortException など) がいつでもスローされる可能性があることを意味します。特に、 の前後にスローされる可能性がありnumAdded++ます_list.Insert。この場合、バックアウト コードは から削除する項目が少なすぎます_list。

これを考えると、この例の制約付き実行領域の目的を理解するのに苦労しています。

これについての私の理解は正しいですか、それとも何かを見逃していますか?

Microsoft Azure クラウドにサービスをアップロードするには、ID を証明するために cer ファイルが必要です。会社用に購入するにはどうすればよいですか?

ありがとう、

うまくいけば、これはSOにとってあまり曖昧ではありませんが、次のP/Invoke署名を検討してください。

次のように、SafeHandlesを使用するようにこの署名を再設計したいと思います。

ただし、MSDNによると、HandleType引数がSQL_HANDLE_ENVの場合、InputHandle引数はnullポインターである必要があり、それ以外の場合はnull以外のポインターである必要があります。

これらのセマンティクスを単一のP/Invoke署名に取り込むにはどうすればよいですか？回答にコールサイトの例を含めてください。私の現在の解決策は、2つの署名を使用することです。

サードパーティ システムの初期化に使用するスレッドは、それを終了するために使用するスレッドと同じでなければならないという、非常に厄介な相互運用の問題があります。これを行わないと、デッドロックが発生します。IIS でホストされている WCF サービスから相互運用を実行しています。現在、このクリーンアップは処分で行われており、通常は非常にうまく機能します。残念ながら、重い負荷がかかると、IIS は無作法なアンロードを実行するため、dispose を呼び出すことはできません。シャットダウン ロジックを重要なファイナライザーに移動することはできますが、初期化スレッドにアクセスできないため、それは役に立ちません。現時点では、AppDomain が破損した状態にある可能性が高いことを CLR に通知することが唯一の手段のようです。ただし、それを行う方法がわかりません（または可能かどうかさえわかりません）。これはクラスレベルでの契約の有用性かもしれませんが、そうではないことを認めます.

編集: あるいは、これはファイナライザーのスレッド アフィニティの問題と見なすこともできます。誰かがそれに対する賢い解決策を持っているなら、私はすべて耳にします:)

現在、Microsoft の SignCode ツールと (GlobalSign の) 証明書を使用して EXE ファイルに署名する際に、興味深い問題が発生しています...

そのため、現在の証明書が間もなく期限切れになるため、新しい証明書を購入しました。元の形式は JKS です。この証明書を .JKS から .CER にエクスポートしたので、ルートの信頼できる証明書セクションでローカル マシンにインストールできます。インストールしましたが、certmgr.msc を開くと表示されますが、[コントロール パネル] -> [インターネット オプション] -> [コンテンツ] -> [証明書] -> [ルートの信頼できる証明書] などを開くと表示されません。ここにもあるといいなと思いました。

signcode.exe ツールを実行すると、「正しい秘密鍵で csp プロバイダーを開くことができません」というエラー メッセージが表示されます。

ノート！古い証明書でテストすると機能するため、signcode.exe コマンドは正しいです。

お知らせ下さい。

前もって感謝します！サージ