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

Я использую NuGet довольно долгое время на конкретном ПК. Теперь я создал новый проект в VS2010 (это проект MVC 4 Beta с использованием шаблона приложения Single page, если это имеет значение). Когда я выбираюПочему поведение ExecutionPolicy зависит от разных проектов в Visual Studio?

Tools/Library Package Manager/Package Manager Console

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

File 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 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.

Однако другие проекты могут еще открыть и использовать Диспетчер пакетов консоли.

В каждом случае VS2010 работает как один и тот же пользователь.

Если открыть командную строку (используя ту же учетную запись, под которой VS2010 запущен), запустите PowerShell, и введите команду

Get-ExecutionPolicy

PowerShell возвращает

Restricted

Мое понимание, основанные на Scott Hanselman blog - это то, что скрипты не должны запускаться вообще, если ExecutionPolicy ограничена.

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

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

источник

2012-05-04 Eric J.

Консоль диспетчера пакетов NuGet устанавливает политику выполнения PowerShell для RemoteSigned, а область действия - «Процесс», поэтому она влияет только на Visual Studio. Изменение политики для Visual Studio не требует, чтобы Visual Studio запускалась как администратор. Не следует изменять политику выполнения, которую вы видите из командной строки. На моей машине установлено значение Ограничено. Однако ничто из этого не объясняет, почему ваш новый проект показывает эту ошибку, а существующие нет. –

Какой смысл устанавливать политику на машинке, если пользователь, не являющийся администратором, может изменить политику на основе каждого процесса? –

Параметры групповой политики могут помешать вам переопределить настройки текущего процесса, но настройки локального компьютера сами по себе не работают. См. Раздел приоритета политики выполнения в сообщении msdn - http://technet.microsoft.com/en-us/library/dd347641.aspx –

122

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

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

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

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

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

источник

2012-05-23 10:56:24 Murries

Ницца, это сработало, как объяснено! –

+1 О, да! Это Windows. Мне просто нужно перезагружать материал, пока он не сработает. ;) – Nick

Не требуется перезагрузка на моей стороне для VS. –

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

От How to Tell if PowerShell is 32-bit or 64-bit:

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

источник

2014-06-17 18:20:55 cat5dev

Я попытался запустить только «Set-ExecutionPolicy RemoteSigned», и это не сработало. Я могу подтвердить, что мне также пришлось запустить «Set-ExecutionPolicy Unrestricted». –

+1 Я впервые столкнулся с этой ошибкой в первый раз, я, по-видимому, использовал только свою политику powershell, установленную на одной из 2-х энергетических оболочек ... Что-то, что я только что заметил, у вас есть 32-битная и 64-битная фраза в вашем посте? У вас 32bit с SysWow64 и 64 бит с System32. Это кажется обратным. –

Спасибо Крису. Я скопировал его из связанной статьи, в которой у них есть флип-флоп. Это обновление. – cat5dev

Другой способ исправить это путем слияния файл 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.

источник

2014-07-09 10:35:44

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

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

источник

2014-09-08 19:38:55 sargeMonkey

Кажется, что он дает ответ на мой вопрос. Ответ можно перефразировать как «Возможно, вы сможете это решить, не используя Visual Studio в качестве администратора». –

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

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

источник

2014-12-30 12:02:52 Gustyn

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

источник

2015-04-06 23:16:14

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

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

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

источник

2015-06-11 13:46:10 Leak

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

источник

2015-09-28 19:13:49

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

ответ

Смежные вопросы