Visual Studio でアセンブリ署名を作成・登録しようとするとエラーがでる (解決済み)

環境

  • Windows 10 Pro
  • Visual Studio 2015 Community

現象

環境を Windows 10 (新規)に移行して Visual Studio 2015 を入れたのですが、以前のプロジェクトを編集していると一部のプロジェクトでアセンブリ署名がうまく設定されない現象に出くわしました。

原因を探るために新規プロジェクトを作成して試してみました。今回はコンソールアプリケーションです。プロジェクトを作成しただけで特に何も追加していません。

2015-09-16 22_34_37-3D Builder

プロジェクトのプロパティを開き、アセンブリの署名キーを作成します。

2015-09-16 22_35_20-3D Builder

ファイル名とパスワードを入力します。

2015-09-16 22_35_44-厳密な名前キーの作成

しかし、「操作を完了できませんでした。アクセスが拒否されました。」のエラーメッセージが出てしまいました。

2015-09-16 22_36_23-Microsoft Visual Studio

プロジェクトにもキーファイルは追加されていません。

2015-09-16 22_36_36-3D Builder

ただ、エクスプローラーを見るとファイルだけは作成されているようです。

2015-09-16 22_36_46-

試しに、このpfxファイルを参照して設定してみます。

2015-09-16 22_36_57-3D Builder

作成されたpfxファイルを選択します。

2015-09-16 22_37_05-3D Builder

先ほど入力したパスワードを入力します。

2015-09-16 22_37_15-ファイルを開くためのパスワードを入力してください。

しかし今度は「存在しないトークンを参照しようとしました。」というエラーメッセージが表示されました。

2015-09-16 22_37_18-キーのインポート エラーです。

もちろん、キーファイルは設定されていません。

2015-09-16 22_37_26-3D Builder

しかし、今度はプロジェクトには追加されているようです。

2015-09-16 22_37_31-3D Builder

解決方法

正規の解決方法なのかはわかりませんがうまく対応できたので手順を載せておきます。

いろいろ調べてみると「C:ProgramDataMicrosoftCryptoRSAMachineKeys」フォルダに対して更新権限がないために起こっているエラーのようでした。試しに、そのフォルダに対してファイルを作成しようとしても作成できないことが確認できます。

2015-09-16 22_38_56-MachineKeys

ちなみに、正常に動作している環境ではファイルが作成できるようになっていました。

2015-09-16 22_39_42-yuuichi-main_3404 - リモート デスクトップ接続

なぜこのような違いが起こったのかわかりませんが、とりあえずログインしているユーザーでフルコントロールを割り当ててみました。ちなみに正常に動作している環境のセキュリティを確認したところ、「Everyone」「Administrators」のみで、どちらもアクセス許可にはすべてチェックはついていませんでした。

2015-09-16 22_40_20-MachineKeys のアクセス許可

セキュリティの設定を行ったところ、作成したプロジェクトでキーファイルが設定できるようになりました。

2015-09-16 22_41_54-OneNote

もともと正常に動作している環境、動作しなかった環境はいずれも「Windows 10 Pro」「Visual Studio 2015 Community」なのですが、Windows 10 に移行した際の手順によってもしかしたら違いが出たのかもしれません。

Windows 10 新規インストール OK
Windows 8.1 Professional から Windows 10 へアップグレード OK
Windows 8.1 Enterprise から Windows 10 へアプリ以外をアップグレード NG

また、今回は「C:ProgramDataMicrosoftCryptoRSAMachineKeys」フォルダにセキュリティのアクセス許可を追加しましたが、セキュリティ的にリスクがないかどうかはよくわかっていません。試される方はその点を認識したうえで行ってください。

]]>

ASP.NET アプリケーションをデバッグ実行したときに「AspAccessCheck~.tmp」へのアクセス拒否のエラーに対処する

メモ書きです。

環境

  • Visual Studio 2013
  • .NET Framework 4.5

内容

原因がよくわかっていないのですが、Visual Studio で ASP.NET アプリケーションをデバッグ実行したときに以下のエラー(例外)が表示されて、その後の処理が正常に行われない現象が発生する場合があります。

型 'System.UnauthorizedAccessException' の初回例外が mscorlib.dll で発生しました

追加情報:パス 'C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Files~AspAccessCheck_71d98a9c21352.tmp' へのアクセスが拒否されました。

※「71d98a9c21352」はたぶん一時的に決められた値

これを解決するには「C:WindowsMicrosoft.NETFrameworkv4.0.30319」フォルダにある「Temporary ASP.NET Files」フォルダを削除してしまいます。たぶんフォルダの中には何も入っていないはずです。削除後デバッグ実行すると正常に動作する場合があります。(実行しても Temporary ASP.NET Files フォルダは作成されないようです)

]]>

Windows 認証、または SQL Server 認証 sa ユーザー以外のユーザーに SQL Server エージェントのジョブ実行権限を付与する方法

メモ書きです。

  1. SQL Server Management Studio から「セキュリティ」-「ログイン」を開き、対象ユーザーのプロパティを開く
  2. 「ユーザーマッピング」を選択し、「msdb」にチェックを入れる。
  3. さらに msdb を選択した状態でメンバーシップから以下のメンバーシップにチェックを入れる
    • SQLAgentUserRole
    • SQLAgentReaderRole
    • SQLAgentOperatorRole
  4. 後はプログラムなどから対象ユーザーの接続文字列を使用してジョブが実行されるかチェックする
]]>

DCOM を使用して Excel を実行する際の実行ユーザーアカウントを強制的に変更する

【概要】

通常 DCOM を使用して Excel オブジェクトを扱った場合、Excel の実行権限はプログラムを実行したユーザーの権限になります。Administrators で実行した場合は Administrators、Users 権限であれば Users, IIS から起動した場合は IIS ユーザー(IIS のバージョンや設定によって名前が変わるので IIS ユーザーとします)となります。

しかし、プログラムの実行ユーザーによって権限がないために本来使用したい機能があったとしても使用できずにエラーになってしまう場合があります。そういう場合は DCOM の実行権限を強制的に特定のユーザーの権限にしてしまう方法があります。

ただし、一般ユーザーであるにもかかわらず Administrators 権限で実行させることもできてしまいますので、セキュリティ観点で十分に注意する必要があります。

【手順】

  1. スタートメニューのプログラムとファイルの検索入力で「dcomcnfg」と入力して「dcomcnfg.exe」を実行
  2. 「コンポーネント サービス」⇒「コンピューター」⇒「マイ コンピューター」⇒「DCOMの構成」を展開し、「Microsoft Excel Application」を右クリックし、「プロパティ」を選択
  3. プロパティが開いたら「ID」タブを選択し、ユーザーから「このユーザー」を選択、実行したときに与える権限を持つユーザーとパスワードを入力
]]>