visual studio 2010 - tutorial - ¿Por qué el comportamiento de ExecutionPolicy varía según los proyectos en Visual Studio?

visual studio code ejemplos

Question

He estado usando NuGet durante bastante tiempo en una PC en particular. Ahora, creé un nuevo proyecto en VS2010 (es un proyecto MVC 4 Beta usando la plantilla de la aplicación de una sola página, si eso es importante). Cuando selecciono

Herramientas / Library Package Manager / Package Manager Console

La ventana de la consola se abre pero muestra el error:

No se puede cargar archivo C: / Archivos de programa (x86) / Microsoft Visual Studio 10.0 / Common7 / IDE / Extensions / Microsoft Corporation / NuGet Package Manager / 1.7.30402.9028 / Modules / NuGet / profile.ps1 porque la ejecución de scripts está deshabilitada en este sistema. Consulte "get-help about_signing" para obtener más detalles.

Sin embargo, otros proyectos aún se pueden abrir y usar Package Manager Console.

En cada caso, VS2010 se está ejecutando como el mismo usuario.

Si abro un símbolo del sistema (usando la misma cuenta bajo la cual se está ejecutando VS2010), inicie PowerShell e ingrese el comando

Get-ExecutionPolicy

PowerShell regresa

Restringido

Mi comprensión basada en un blog de Scott Hanselman es que las secuencias de comandos no deberían ejecutarse si ExecutionPolicy está restringido.

¿Por qué los proyectos existentes pueden usar la consola de Package Manager mientras que uno nuevo no?

Actualización: Cambiar la ExecutionPolicy a AllSigned y reiniciar VS2010 resuelve el problema inmediato, pero mi pregunta principal es por qué los otros proyectos pudieron eludir la ExecutionPolicy establecida. VS2010 no se está ejecutando como administrador.

Answer 1

Además de la respuesta de Murries , encontré la publicación de jellonek (en otro hilo) útil. Es posible que tenga que cambiar los permisos en una versión diferente de PowerShell (las versiones de 32 y 64 bits requieren permisos por separado).

De Cómo saber si PowerShell es de 32 bits o de 64 bits :

• Ruta de 64 bits de PowerShell: C: / Windows / System32 / WindowsPowerShell / v1.0 / powershell.exe
• Ruta de 32 bits de PowerShell: C: / Windows / SysWOW64 / WindowsPowerShell / v1.0 / powershell.exe

Además, BOTH de estos deberían funcionar:

• Set-ExecutionPolicy RemoteSigned
• Set-ExecutionPolicy sin restricciones

Answer 2

Como necesitábamos crear un proyecto en un recurso compartido en un servidor remoto de nuestra red y tuvimos problemas similares, esto es lo que funcionó:

• asignar el recurso compartido como un disco de red, digamos R: (pero supongo que también funcionaría sin este mapeo)
• abra las opciones de Internet> Seguridad> Intranet local> Sitios> Avanzado (a través de IE o panel de control)
• agregue "R" o "file: //server.domain.xy" (el primero se convertirá automáticamente en el último una vez que vuelva a abrir el diálogo)
• ejecutar el ejecutable PowerShell x86 y hacer "Set-ExecutionPolicy RemoteSigned"

Una vez que hice todo eso, Visual Studio no se quejó de que el proyecto estaba en una ubicación no confiable al volver a abrir la solución y ejecutó con éxito todos los scripts de PowerShell para los paquetes que se instalan automáticamente al crear una nueva aplicación MVC.

Answer 3

Es posible que pueda resolver esto al no ejecutar Visual Studio como administrador.

Causa diferente, mismo mensaje de error; podría ser útil para alguien que se encuentra con este.

Answer 4

Estoy teniendo este problema ahora, creo que lo que funcionó para mí fue que tuve que reiniciar Visual Studio 2013 y ejecutarlo como administrador ... funcionó rápido para mí.

Answer 5

Experimenté el mismo problema y lo resolví de la siguiente manera:

• Apertura de Powershell como administrador
• Ingresando el siguiente comando "Set-ExecutionPolicy RemoteSigned"
• Reiniciar Visual Studio y la consola del Administrador de paquetes funcionó como se esperaba

Sin embargo, es importante señalar que Powershell le dará una advertencia

"La política de ejecución ayuda a protegerlo de scripts en los que no confía. Cambiar la política de ejecución puede exponerlo a los riesgos de seguridad descritos en el tema de ayuda about_Execution_Policies. ¿Desea cambiar la política de ejecución?"

Y debe tener cuidado de habilitar esta característica y debe leer más información en los temas de ayuda sobre los riesgos de seguridad.

Answer 6

He tenido este problema intermitentemente también. Acabo de encontrarlo de nuevo y encontré este hilo. En mi último caso, me di cuenta de que tenía VS 2013 abierta dos veces (lo que normalmente no es un problema, lo hago todo el tiempo). Dado que el único tema común de otros que parecía solucionarlo estaba relacionado de manera circunstancial con la necesidad de privilegios de administrador, di una oportunidad y cerré ambas instancias de VS y volví a abrir mi solución en una nueva instancia. Ejecutó la instalación nuget y funcionó sin problemas.

En base a esto, creo que es un problema de permiso de archivo que causa este error espurio. Algo así como cuando Windows tiene un bloqueo en un archivo en el directorio bin después de una sesión de depuración y no le permite compilar la solución.

Answer 7

Otra forma de solucionar esto es fusionar un archivo Regedit con el siguiente contenido:

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"

(Cree un archivo de texto llamado NuGetPowerShellFix.txt, copie y pegue lo anterior en él, cambie el nombre a NuGetPowerShellFix.reg y luego ejecútelo).

Después de fusionar el archivo anterior, reinicie Visual Studio.

Answer 8

Si está utilizando NuGet en Visual Studio 2013 y obtiene este molesto error, vaya a Herramientas | NuGet Package Manager | Configuración del Administrador de paquetes y haga clic en "Borrar caché de paquetes". Reinicie Visual Studio. Sé que hay múltiples soluciones para esto, así que este es otro para probar.