visual-studio-2010 - validar - visual studio code español

VSTS 2010 SGEN: error: No se pudo cargar el archivo o el ensamblaje(Excepción de HRESULT: 0x80131515)

Question

Estoy experimentando un problema extraño con VS2010. Usamos TFS para construir nuestros dlls de API y solíamos hacer referencia a ellos en nuestros proyectos. Usamos una unidad de red mapeada en la que se confiaba plenamente. Hemos estado trabajando así durante al menos dos años y todo funcionó a la perfección.

Hoy, convertí una aplicación web a vs2010 y cuando la compilo en Release, me está dando:

SGEN: error: no se pudo cargar el archivo o ensamblado ''file: /// L: / Api / Release API_20100521.1 / Release / CS.API.Exceptions.dll'' o una de sus dependencias. La operación no es compatible. (Excepción de HRESULT: 0x80131515)

Lo extraño es que está funcionando cuando está bajo el perfil de depuración ...

Intenté agregar el

<runtime>
   <loadFromRemoteSources enabled="true" />
</runtime>

en app.config y aún sin suerte (ver http://social.msdn.microsoft.com/Forums/en/msbuild/thread/d12f6301-85bf-4b9e-8e34-a06398a60df0 y http://msdn.microsoft.com/en-us/library/dd409252(VS.100).aspx )

Estoy bastante seguro de que este problema es de visual studio o msbuild, ya que nuestro código no se ejecutará desde un recurso compartido de red cuando está en prod porque todos los dll referenciados se copian en la carpeta bin.

Si alguien tiene una solución (o simplemente una idea para una ruta de búsqueda), ¡por favor hágamelo saber!

Editar: Resulta que estaba trabajando en el modo de depuración porque la generación de ensamblajes de serialización estaba desactivada. Como dice el título, es realmente un problema de SGEN, ya que es esta utilidad la que dice que no se confía en la ruta ...

Answer 1

Acabo de tener el mismo problema / similar en un servidor de compilación TFS donde una compilación hacía referencia a dll desde un recurso compartido de red.

El problema es que el modelo de política de seguridad de CLR v4 ha cambiado desde versiones anteriores y no son ensamblados de sandboxing como antes.

Para solucionar su problema, simplemente busque la ubicación de sgen.exe y cree un sgen.exe.config en la misma carpeta con los siguientes contenidos:

<configuration>
  <runtime>
    <loadFromRemoteSources enabled="true" />
  </runtime>
</configuration>

sgen.exe generalmente está en

"C:/Program Files/Microsoft SDKs/Windows/v[current version]/bin/NETFX 4.0 Tools"

Puede leer sobre algunos de los cambios en las políticas de CAS en .NET 4.0 en esta entrada de blog: Link

Answer 2

Agregando el fragmento de abajo al archivo app.config funcionó en mi caso. Estoy ejecutando Windows XP, con el paquete de servicio VS2010 1.

<configuration>
  <runtime>
    <loadFromRemoteSources enabled="true" />
  </runtime>
</configuration>

Answer 3

Al igual que un FYI si está ejecutando Windows 7, el archivo sgen.exe se puede encontrar en:

C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin / NETFX 4.0 Tools

Tuve que crear un sgen.exe.config y colocarlo allí y luego este problema desapareció.

Answer 4

Ni el unblock ni la config funcionaron para mí. ¿Cuál fue el truco para mí fue este consejo sobre caspol ? corrí

 %windir%/Microsoft.NET/Framework/v2.0.50727/CasPol.exe -m -ag 1.2 -url file://UncPathName/UncSubPath/* FullTrust

Y estaba listo para empezar, ni siquiera se requiere un reinicio de VisualStudio.

Answer 5

Obtuve un problema similar y finalmente lo supere al eliminar el archivo licenses.licx en la carpeta de propiedades de la solución.

Answer 6

Para aquellos de ustedes que ejecutan una versión de 64 bits del servicio de compilación TFS, tuve que crear el archivo de configuración en la siguiente ruta:

 C:/Program Files (x86)/Microsoft SDKs/Windows/v8.0A/bin/NETFX 4.0 Tools/x64

Y el contenido del archivo:

<?xml version ="1.0"?>
<configuration>
<runtime>
    <loadFromRemoteSources enabled="true" />
</runtime>
</configuration>

Answer 7

Pude solucionar este error buscando el archivo DLL ensamblado en el Explorador de Windows, haciendo clic con el botón derecho, seleccionando Propiedades y presionando el botón "Desbloquear". La DLL tiene una secuencia que lo está marcando como un archivo externo, y al hacer clic en desbloquear, se elimina esa designación.

Answer 8

Solo en caso como yo, Desbloquear no fue una solución, ya que Desbloquear no aparece en las propiedades de mi archivo dll. Seguí mirando y terminé cerrando el archivo de mi solución y volviendo a abrir usando la ruta local C: copiar en lugar de la red UNC para proyectar el archivo sln. Pude publicar después de seguir esta ruta.

Answer 9

Tenía el mismo problema y el cambio de configuración no funcionó. Solo cuando configuré Generate Serialization Assambly en off en las propiedades del proyecto, funcionó.

Answer 10

Tuve el mismo error y encontré que mi archivo DLL estaba "bloqueado". Abra la DLL en el explorador, haga clic derecho -> propiedades -> presione ''Desbloquear''.

http://cantgrokwontgrok.blogspot.com/2009/10/visual-studio-unknown-build-error.html

Answer 11

Tuve el mismo problema, cargué la asamblea en el GAC y trabajé

Answer 12

Tuve este mismo problema y lo solucioné agregando sgen.exe.config en C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin / NETFX 4.0 Tools

con esta configuración simple como otros han dicho

<?xml version ="1.0"?>
<configuration>
  <runtime>
    <loadFromRemoteSources enabled="true" />
  </runtime>
</configuration>