特定のPCでかなり長い間NuGetを使用しています。次に、VS2010で新しいプロジェクトを作成しました(それが重要な場合は、シングルページアプリテンプレートを使用したMVC 4ベータプロジェクトです)。選択したとき
ツール/ライブラリパッケージマネージャー/パッケージマネージャーコンソール
コンソールウィンドウは開きますが、エラーが表示されます。
ファイルC:\ Program Files(x86)\ Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\1.7.30402.9028\Modules\NuGet\profile.ps1は、スクリプトの実行が無効になっているためロードできませんこのシステム。詳細については、「get-help about_signing」を参照してください。
ただし、他のプロジェクトでもパッケージマネージャーコンソールを開いて使用できます。
いずれの場合も、VS2010は同じユーザーとして実行されています。
コマンドプロンプトを開いた場合(VS2010を実行しているアカウントと同じアカウントを使用)、PowerShellを起動して、コマンドを入力します
Get-ExecutionPolicy
PowerShellが返す
制限あり
Scott Hanselman blog に基づく私の理解では、ExecutionPolicyが制限されている場合、スクリプトはまったく実行されません。
既存のプロジェクトがパッケージマネージャーコンソールを使用できるのに、新しいプロジェクトは使用できないのはなぜですか?
更新:ExecutionPolicyをAllSignedおよびに変更すると、VS2010を再起動することで差し迫った問題は解決しますが、主な質問は、他のプロジェクトが確立されたExecutionPolicyをバイパスできた理由です。 VS2010は管理者としてnotを実行しています。
私は同じ問題を経験し、次の方法で解決しました。
ただし、Powershellから警告が表示されることに注意してください
"実行ポリシーは、信頼できないスクリプトからユーザーを保護するのに役立ちます。実行ポリシーを変更すると、about_Execution_Policiesヘルプトピックで説明されているセキュリティリスクにさらされる可能性があります。実行ポリシーを変更しますか? "
また、この機能を有効にすることに注意し、セキュリティリスクに関するヘルプトピックの詳細を読む必要があります。
Murriesの答え に加えて、 jellonekの投稿 (別のスレッド)参考。 PowerShellの異なるバージョンのアクセス許可を変更する必要がある場合があります(32ビットバージョンと64ビットバージョンでは、個別のアクセス許可が必要です)。
から PowerShellが32ビットか64ビットかを知る方法 :
また、 [〜#〜] both [〜#〜] の両方が機能するはずです:
これを修正する別の方法は、Regeditファイルを次のコンテンツとマージすることです。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"
(NuGetPowerShellFix.txtというテキストファイルを作成し、上記にコピーして貼り付け、NuGetPowerShellFix.regに名前を変更して実行します。)
上記のファイルをマージした後、Visual Studioを再起動します。
Visual Studio 2013でNuGetを使用していて、この迷惑なエラーが発生する場合は、[ツール] | [ NuGetパッケージマネージャー| [パッケージマネージャーの設定]をクリックし、[パッケージキャッシュのクリア]をクリックします。 Visual Studioを再起動します。これには複数の解決策があることを知っているので、これはもう1つの試みです。
この問題も断続的に発生しました。私は再びそれに出くわし、このスレッドに出くわしました。私の最新のケースでは、VS 2013を2回開いていることに気付きました(通常、これは問題ではありません。いつもやっています)。それを修正するように見える他の人の唯一の共通のテーマは、管理者権限の要求に状況的に関連しているので、私はそれを試してVSの両方のインスタンスを閉じ、新しいインスタンスでソリューションを再び開きました。 nugetのインストールを実行すると、問題なく動作しました。
これに基づいて、この偽のエラーを引き起こすファイル許可の問題であると考えています。デバッグセッション後にWindowsがbinディレクトリ内のファイルをロックし、ソリューションをコンパイルできない場合に似ています。
Visual Studioを管理者として実行しないことで、これを解決できる場合があります。
異なる原因、同じエラーメッセージ。これに遭遇した人に役立つかもしれません。
ネットワーク内のリモートサーバー上の共有にプロジェクトを作成する必要があり、同様の問題に遭遇したため、ここで機能しました。
ソリューションを開くときにプロジェクトが信頼できない場所にあることをVisual Studioが文句を言わず、新しいMVCアプリケーションの作成時に自動インストールされるパッケージのすべてのPowerShellスクリプトを正常に実行しました。
私は今この問題を抱えています、私にとって簡単に働いたのは、Visual Studio 2013を再起動して管理者として実行するだけだったと思います...私のために速く働きました。