web-dev-qa-db-fra.com

ALINK: avertissement AL1073: l'assembly référencé 'mscorlib.dll' cible un processeur différent

Nous utilisons VS2013 et .Net 4.5.1 (récemment migré, mais cette erreur provient de .Net 4.0). Cette erreur se produit uniquement lors de la compilation du projet dans la plate-forme cible x64. Est-ce vraiment une erreur qui se cassera lors de l'exécution? Pourquoi MSBUILD ne résout pas correctement ce mrcorlib.dll? Cela se produit uniquement dans les projets créés dans VS2010 et ne se produit pas dans les projets nouvellement créés. Qu'est-ce que j'oublie ici. Tous mes assemblages tiers sont en x64bit.

Dans le serveur de build TeamCity, j'obtiens l'erreur suivante:

GenerateSatelliteAssemblies
[17:01:18]AL
[17:01:18]C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\AL.exe /culture:de /keyfile:..\..\MyApp.snk /out:obj\x64\Release\de\MyApp.Hardware.Softing.resources.dll /platform:x64 /template:obj\x64\Release\MyApp.Hardware.Softing.dll /embed:obj\x64\Release\MyApp.Hardware.Softing.Properties.Resources.de.resources
[17:01:18]ALINK warning AL1073: Referenced Assembly 'mscorlib.dll' targets a different processor
c#.netvisual-studio-2010msbuildvisual-studio-2013
26
jero2rome

Alors que le bogue référencé par @ jero2rome est fermé comme ne se corrige pas, VS2015 RC avec .NET 4.6 n'émet plus cet avertissement:

De VS2013/.NET 4.5.1, je verrais le même problème:

GenerateSatelliteAssemblies:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\AL.exe /culture:zh-CHT /out:obj\x64\Debug\zh-CHT\MyComponent.resources.dll /platform:x64 /template:obj\x64\Debug\MyComponent.dll /embed:obj\x64\Debug\MyComponent.Resources.string.zh-CHT.resources
ALINK : warning AL1073: Referenced Assembly 'mscorlib.dll' targets a different processor [c:\svn\project\MyComponent.csproj]

Avec VS2015 RC/.NET 4.6, aucun avertissement n'est émis:

GenerateSatelliteAssemblies:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64\AL.exe /culture:zh-CHT /out:obj\x64\Debug\zh-CHT\MyComponent.resources.dll /platform:x64 /template:obj\x64\Debug\MyComponent.dll /embed:obj\x64\Debug\MyComponent.Resources.string.zh-CHT.resources
7
dirtybird

Voici une solution de contournement:

Le problème peut être évité en utilisant l'AL.EXE qui correspond à la plate-forme (ou bitness) que vous essayez de créer. Autrement dit, vous verrez que lorsque vous générez x64, il essaie d'utiliser AL.EXE sur un chemin similaire à

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools

Si vous parvenez à utiliser la version x64 d'AL.exe, le problème disparaîtra. Autrement dit, utilisez AL.EXE à un chemin similaire à:

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64

Msbuild trouve ce chemin en utilisant son TargetFrameworkSDKToolsDirectory. Ainsi, en utilisant l'hypothèse que ce répertoire est le répertoire correct lors de la construction de x86, la solution de contournement ci-dessous ajoute essentiellement le sous-répertoire x64 au chemin lors de la construction de x64 et le laisse tel quel:

  1. Créez un fichier MsBuildAL1073WarningWorkaround.targets (le nom n'a pas d'importance) et ajoutez-le au projet. Il a le contenu suivant:

    <?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.Microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <TargetFrameworkSDKToolsDirectory Condition=" '$(PlatformTarget)' == 'x64'">$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
  </PropertyGroup>
</Project>

  2. Modifiez le fichier .csproj pour importer ce fichier vers la fin du fichier (où vous verrez le commentaire qui dit "Pour modifier votre processus de construction ...":

     <Import Project="MsBuildAL1073WarningWorkaround.targets" />
 <!-- To modify your build process... -->
30
Matt Smith

Ces avertissements sont affichés dans les projets qui contiennent des assemblys de satellites de localisation (fichiers. Resx) dans la solution.

Il s'agit du bogue du côté de Microsoft et depuis août 2017, Microsoft ne l'a toujours pas corrigé.

Voici la citation de la page MS feedback :

Il résulte d'un bogue logique dans le binaire alink.dll du framework .NET. Mais étant donné l'impact limité de ce problème et le fait que cet outil a une barre très élevée pour le service, nous n'apporterons aucun changement pour résoudre ce problème.

Cordialement,

Ed Maurer Responsable du développement, VB & C # Compilers

11
JerryGoyal

Cet avertissement peut être ignoré en toute sécurité. Depuis .Net chargera les assemblages 64 bits corrects lors de l'exécution dans une machine 64 bits. Néanmoins, Microsoft peut donner une réponse solide à ce problème. C'était une perte de temps inutile d'avertissement.

8
jero2rome

Nous avons eu le même problème et nous nous sommes retrouvés avec la solution de contournement de Matt Smith ( https://stackoverflow.com/a/41945190/350676 ) avec une modification qui l'a fait fonctionner.

En raison de la fonctionnalité/bogue de MsBuild ( https://stackoverflow.com/a/1367309/350676 ), nous devions modifier le fichier de cibles décrit à l'étape 1.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.Microsoft.com/developer/msbuild/2003">
    <Target Name="MsBuildAL1073WarningWorkaround" BeforeTargets="BeforeBuild" >
        <PropertyGroup Condition="'$(Platform)' == 'x64'">
            <TargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)$(Platform)\</TargetFrameworkSDKToolsDirectory>
        </PropertyGroup>
    </Target>
</Project>
5
Jan Peldřimovský

Juste un ajout à la réponse de Matt (je n'ai pas assez de réputation pour ajouter un commentaire): je crois

vers la fin du fichier

est juste après la ligne:

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

J'ai testé et si la ligne ci-dessus précède la (re) définition de $ TargetFrameworkSDKToolsDirectory , alors l'avertissement AL1073 a disparu. Sinon, cela persiste.

3
Levente Koncz