linux ubuntu mono nunit teamcity

TeamCity NUnitLauncher ejecutándose en Linux(mono) da el error "Corlib no está sincronizado con este tiempo de ejecución"



ubuntu (4)

Así es como trabajé a su alrededor: (tenga en cuenta que mi mono está en / opt / mono)

$ cd /opt/mono/lib/mono $ sudo mv 4.0 __4.0 $ sudo ln -s 4.5 4.0

es decir, deshágase de la carpeta 4.0 y enlace simbólico de 4.5 a ser 4.0

Esto es algo así como un truco, pero me puso en marcha hasta que aparezca una solución adecuada.

Steve

Ejecutar un agente de compilación de TeamCity para ejecutar pruebas de NUnit en Ubuntu 14.04 LTC con la última compilación de mono parece tener algunos problemas de dependencia que no puedo resolver por mi cuenta. He seguido los siguientes pasos de instalación

Cuando TC Build Agent inicia el paso NUnit, simplemente falla, y al mirar los registros se muestra que se ejecuta

/usr/bin/mono-sgen /home/ubuntu/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe

que rápidamente regresa con

Corlib not in sync with this runtime: expected corlib version 117, found 111. Loaded from: /usr/lib/mono/4.0/mscorlib.dll Download a newer corlib or a newer runtime at http://www.mono-project.com/download.

¿Hay alguna manera posible de hacer que esto funcione? Intenté eliminar todas las piezas y volver a instalarlas de nuevo, e incluso instalé una versión anterior de la compilación mono, pero fue en vano.

La conexión TC parece funcionar y puedo invocar manualmente y llamar a mono por sí mismo e incluso a nunit-console; sin embargo, esta versión .exe proporcionada por TC parece haber quedado perpleja como linux no experta.

¡Por favor, sálvame del infierno de la dependencia!

Editar : terminé resolviendo mi problema instalando nunit-console y habilitando la función de generación de procesamiento de informe XML en lugar de jugar con los archivos corelib y romper algo más.


Tuve este problema en mi Raspberry Pi después de compilar 4.0.2 pero estaba cargando desde /4.5/

Esto me puso en marcha:

sudo mv /usr/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5/_old_mscorlib.dll sudo cp /opt/mono-4.0.2/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5


Reemplazar la versión de mscorlib solo está pidiendo problemas, es decir, TypeLoadException y sus amigos están esperando a la vuelta de la esquina para atraparte.

Lo que hice fue reemplazar el paso de compilación de Teamcity con una invocación manual de TC NunitLauncher, pero forzándolo a usar Mono 4.5:

mono --runtime=4.5 /Applications/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe v4.0 MSIL NUnit-2.6.3 $(find **/bin/Release/*Tests.dll | paste -sd ";" -)

La invocación utiliza algunos trucos de shell para encontrar todos los ensamblajes que me interesan usando un comodín, pero aparte de eso debería ser fácil de entender.

Sería bueno si Mono arreglara su tiempo de ejecución roto 4.0. ¿Alguien ya lo informó en https://bugzilla.xamarin.com/ ?


Este es un error Mono, ver https://bugzilla.xamarin.com/show_bug.cgi?id=34675 .

El problema es que Mono pasó a proporcionar los ensamblados 4.0, incluido mscorlib.dll, solo en forma de ensamblados de referencia. Contienen solo metadatos y están destinados al compilador. Normalmente las aplicaciones solo usan la versión más nueva automáticamente.

Sin embargo, el código del cargador en Mono no se actualizó para vincular una versión explícita en tiempo de ejecución de v4.0.20506 o v4.0.30128 que TeamCity está utilizando en sus archivos .exe.config a la última versión. En su lugar, el tiempo de ejecución intenta cargar mscorlib.dll desde el directorio 4.0 y se libera ya que la versión es demasiado antigua (desde el momento en que se generaron los ensamblados de referencia).

Como solución <build agent installdir>/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe.config , puede editar <build agent installdir>/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe.config (y otros archivos .exe.config) y eliminar las siguientes líneas:

<supportedRuntime version="v4.0.20506"/> <supportedRuntime version="v4.0.30128"/>

Sin embargo, esto podría dejar de funcionar una vez que TeamCity decida actualizar el complemento.