2010-11-02 7 views
14

quand je construis version 64 bits de mon application .net avec Stuido visuel 2008 sur Windows Server 2003 je reçoisCS1607 avertissement du compilateur lors de la construction de la version 64 bits

avertissement CS1607: génération Assemblée - Assemblée Referenced « mscorlib.dll » cible un autre processeur

Cela signifie-t-il que je n'ai pas installé la version x64 de .NET?

rapport complet est ici

16> C: \ WINDOWS \ Microsoft.NET \ Framework \ v3.5 \ Csc.exe /noconfig/nowarn: 1701,1702 /Plate-forme: x64/ErrorReport : invite /define: DEBUG; TRACE /reference:..BIN\Jfc.Dealing\Jfc.Configuration.ConfigurationLayer.dll /reference: ......... . \ BIN \ Jfc.Dys.dll /reference:D:\Projects\dzhukov\SourceCode_Integration_branch\TradeProcessor\Jfc\QuikExport\bin\x64\Debug\QuikExport.dll/référence: D: \ Projects \ dzhukov \ SourceCode_Integration_branch \ Samples \ JFC \ FxGate \ QuoteFeedWcfRemoteControl \ bin \ x64 \ Debug \ QuoteFeedWcfRemoteControl.dll /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.configuration.dll /référence: "c: \ Program Files \ Reference \ Microsoft \ Framework \ v3.5 \ System.Core.dll " /reference:" c: \ Program Files \ Reference Assemblys \ Microsoft \ Framework \ v3.5 \ System.DataSetExtensions.dll "/ référence: C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ System.Data.dll /référence: C: \ WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll/référence: C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ System.Messaging.dll /reference: "C: \ Program Files \ Reference Assemblys \ Microsoft \ Framework \ v3.0 \ System.Runtime.Serialization.dll" /reference: "C: \ Program Files \ Reference Assemblys \ Microsoft \ Framework \ v3.0 \ System.ServiceModel.dll" /reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System. Xml.dll /reference: "c: \ Program Files \ Reference Assemblys \ Microsoft \ Framework \ v3.5 \ System.Xml.Linq.dll" /déboguer +/déboguer: full/filealign: 512 /out: obj \ x64 \ Debug \ FeedRawQuotes.exe /target: exe FeedRawQuotes.cs FeedRawQuotesConfiguration.cs MSMQFeed.cs Program.cs Propriétés \ AssemblyInfo.cs avertissement CS1607: génération d'assemblage - ensemble référencé « System.Data.dll ' cible un avertissement de processeur différent CS1607: génération de l'Assemblée - Assemblée Referenced « mscorlib.dll » vise un processeur différent

+1

Veuillez donner plus de détails - à quelle version du cadre construisez-vous et sur quoi reposez-vous? –

Répondre

34

Ceci est un avertissement normal, vous obtiendrez toujours quand vous ciblez explicitement x64. Il ne sera pas un problème au moment de l'exécution, car sur une machine 64 bits, le GAC stocke une version spécifique 64 bits de mscorlib.dll.

Version longue: plusieurs assemblys .NET contiennent du code non géré. Ce qui les rend sensibles à la bêtise du processus qui les utilise. Mscorlib.dll est l'un d'entre eux, System.Data.dll et les assemblys WPF sont d'autres exemples. Microsoft a résolu ce problème en créant deux versions de ces assemblages, une version 32 bits et une version 64 bits. Le GAC peut les stocker tous les deux, résolus par la propriété AssemblyName.ProcessorArchitecture. Le paramètre "normal" pour cette propriété est MSIL, utilisé lorsque l'assembly contient de l'IL pure. Une copie unique de l'assembly peut ensuite être utilisée à la fois par un processus 32 bits et un processus 64 bits.

Les assemblys de référence utilisés par le compilateur sont une copie des assemblys .NET. Le compilateur les utilise uniquement pour leurs métadonnées. Ces copies sont cependant des copies des assemblys 32 bits, elles auront l'architecture ProcessArchitecture à X86 pour les assemblages qui contiennent du code non managé.

Vous pouvez voir où cela se passe, vous compilez pour x64 et le compilateur voit un assembly de référence x86. Assez pour générer un avertissement "ce programme va fonctionner seulement si vous fournissez également la version x64 de l'assemblage". Ce qui est certainement le cas pour les assemblages .NET, mais pas nécessairement pour les vôtres.

Il est peut-être remarquable que cela ait été résolu dans .NET 4.0. Il utilise des assemblages de référence très différents, qui sont stockés dans C:\Program Files (x86)\Reference Assemblies. Contrairement aux assemblys de référence v2, ils sont radicalement différents de la copie dans le GAC. Tout le MSIL leur a été retiré, ils ne contiennent que des métadonnées. Et sont AnyCPU, donc plus d'avertissement. L'outil qui a servi à les créer est intéressant, malheureusement Microsoft ne le partage pas avec nous. Fwiw, ciblant explicitement x64 est presque toujours la mauvaise chose à faire. Cela n'a vraiment d'importance que sur l'assemblage EXE puisque c'est celui qui détermine la quantité de bits du processus. Un assembly DLL n'a pas le choix, le paramètre de construction approprié pour eux est Any CPU afin qu'ils puissent fonctionner dans les deux sens. L'exception rare est que la DLL a une dépendance connue sur un composant non géré, généralement un serveur COM. Ces composants sont généralement disponibles uniquement sous la forme d'images 32 bits; vous obtenez un message d'erreur difficile à diagnostiquer lorsque vous essayez de les charger dans un processus 64 bits ("Classe non enregistrée"). En les forçant à cibler x86, vous obtiendrez une autre exception difficile à diagnostiquer qui est peut-être un peu plus facile pour les yeux, BadImageFormatException. Avoir une dépendance sur le code non managé qui n'est disponible qu'en code 64 bits est assez rare, donc cibler x64 n'a pas beaucoup de sens.

Questions connexes