Почему поведение ExecutionPolicy зависит от разных проектов в Visual Studio?

Я использую NuGet довольно долгое время на конкретном ПК. Теперь я создал новый проект в VS2010 (это проект MVC 4 Beta, использующий шаблон одиночной страницы, если это имеет значение). Когда я выбираю

Инструменты/Диспетчер пакетов библиотек/Консоль диспетчера пакетов

Откроется окно консоли, в котором отображается ошибка:

Файл 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, заключается в том, что скрипты не должны запускаться вообще, если ограничение ExecutionPolicy ограничено.

Почему существующие проекты могут использовать консоль диспетчера пакетов, а новая - нет?

Обновление: изменение ExecutionPolicy на AllSigned и перезапуск VS2010 решает непосредственную проблему, но мой главный вопрос заключается в том, почему другим проектам удалось обойти установленную ExecutionPolicy. VS2010 не работает как администратор.

ОТВЕТЫ

Ответ 1

Я испытал ту же проблему и решил ее:

  • Открытие Powershell в качестве администратора
  • Ввод следующей команды "Set-ExecutionPolicy RemoteSigned"
  • Перезагрузка Visual Studio и консоли диспетчера пакетов работали как ожидалось

Важно отметить, что Powershell даст вам предупреждение

"Политика выполнения помогает защитить вас от несовместимых скриптов. Изменение политики выполнения может привести к рискам безопасности, описанным в разделе справки about_Execution_Policies. Вы хотите изменить политику выполнения?"

И нужно быть осторожным, чтобы включить эту функцию и читать дополнительную информацию в разделах справки об угрозах безопасности.

Ответ 2

Помимо ответа Murries, я нашел сообщение jellonek (по другому вопросу) полезным. Возможно, вам придется изменить разрешения на другую версию PowerShell (для 32-разрядной и 64-разрядной версий требуются отдельные разрешения).

От Как сказать, если PowerShell 32-разрядный или 64-разрядный:

  • 64-битный путь PowerShell: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
  • 32-разрядный путь PowerShell: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

Кроме того, BOTH должны работать:

  • Set-ExecutionPolicy RemoteSigned
  • Set-ExecutionPolicy Unrestricted

Ответ 3

Еще один способ исправить это - слияние файла 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.

Ответ 4

Если вы используете NuGet в Visual Studio 2013 и получаете эту неприятную ошибку, перейдите в раздел "Инструменты | Менеджер пакетов NuGet | Параметры диспетчера пакетов и нажмите" Очистить кеш пакетов". Перезапустите Visual Studio. Я знаю, что для этого есть несколько решений, так что это еще одна попытка попробовать.

Ответ 5

У меня тоже была эта проблема с перерывами. Я только что наткнулся на нее и пробежал по этой теме. В моем последнем случае я понял, что дважды открывал VS 2013 (что обычно не проблема, я делаю это все время). Поскольку единственная общая тема других, которые, казалось бы, исправить, косвенно связана с требованием прав администратора, я дал ей шанс и закрыл оба экземпляра VS и снова открыл мое решение в новом экземпляре. Ранг установил nuget, и он работал без сучка и задоринки.

Исходя из этого, я думаю, что это проблема с разрешением файла, вызывающая эту ложную ошибку. Похоже, когда окна имеют блокировку файла в каталоге bin после сеанса отладки и не позволят вам скомпилировать решение.

Ответ 6

Возможно, вы сможете решить эту проблему, не выполнив Visual Studio в качестве администратора.

Другая причина, то же сообщение об ошибке; может быть полезно для тех, кто сталкивается с этим.

Ответ 7

Так как нам нужно было создать проект на общем ресурсе на удаленном сервере в нашей сети и столкнулись с подобными проблемами, то что сработало:

  • сопоставьте общий ресурс как сетевой диск, скажем R: (но я думаю, что это также сработает без этого сопоставления)
  • открыть параметры Интернетa > Безопасность > Локальная интрасеть > Сайты > Дополнительно (через IE или панель управления)
  • добавьте либо "R:", либо "файл://server.domain.xy" (первый будет автоматически переходить к последнему после открытия диалога)
  • запустите исполняемый файл x86 PowerShell и выполните команду "Set-ExecutionPolicy RemoteSigned"

Как только я сделал все это, Visual Studio не жаловался, что проект был в ненадежном месте после открытия решения снова, и он успешно выполнил все сценарии PowerShell для пакетов, которые автоматически устанавливаются при создании нового приложения MVC.

Ответ 8

У меня эта проблема сейчас, я думаю, что сработало для меня просто, что мне просто пришлось перезапустить visual studio 2013 и запустить ее как администратор... быстро работал у меня.