windows - Visual Studio 2017 x64 miljøproblemer

Indlæg af Hanne Mølgaard Plasc

Problem



Baggrund :

Jeg har fået til opgave at generere en DLL (x64), som kan distribueres og indarbejdes af nogen, der bygger en Windows-applikation. Nu er jeg generelt en Linux/Unix fyr, så noget af dette har trukket mit hår ud. Så jeg installerede VS 2017 Community, og kom til at arbejde.


Problem :

Jeg har nu spildt 2 dage med at forsøge at løse den super hjælpsomme fejl, som VS giver mig:



  Uhåndteret undtagelse: System.BadImageFormatException: Kunne ikke indlæse
  fil eller samling
  'C: \ arbejdsområde \ dll\_test \ bin \ x64 \ Slip \ netcoreapp2.0 \ dll\_test.dll'. en
  Der blev forsøgt at indlæse et program med et forkert format.



Jeg har forsøgt x86/x64/AnyCPU for så vidt som målplatforme, ren, genopbygning, ingen succes.


Løsning :

Så jeg var mere komfortabel i et kommandolinjemiljø, brugte jeg et script til at starte VS Command Line med det rette (x64) miljø via og køre 'x64 Visual Studio Command Line':


CALL "C:Program Files (x86)Microsoft Visual Studio2017CommunityVCAuxiliaryBuildvcvarsall.bat" amd64


Fra dette miljø kan jeg manuelt køre:


csc -out:app.exe Program.cs


Dette resulterer i en ARBEJDE app.exe, som jeg kan udføre og lykkeligt køre fra hvor som helst.


Spørgsmål :

Hvad ville få VS IDE til at fejle, med alle målplatforme, at CMD-liniemiljøet fungerer korrekt? Min eneste antagelse er, at miljøvariabler opsættes af 'CALL' -skriptet, som ikke bliver korrekt installeret i VS IDE. Hvis det er tilfældet, hvordan kan jeg indsnævre, hvad forskellene er? Jeg har ikke noget imod at bruge CmdLine, men de fleste andre, jeg ved, at arbejde i VS ikke kan lide denne løsning. Enhver input er meget værdsat, tak!

Bedste reference


Så jeg regnede endelig med det her. Jeg startede et nyt projekt, kopierede al kode & DLL'er over, og alt fungerede fint fra starten. Dette fik mig til at tænke, måske er det ikke miljøvariabler, men i stedet katalogstrukturen for hvor løsningerne blev åbnet.


Sikker nok, det hele skyldes det faktum, at jeg flyttede projektet fra den oprindelige mappe VS skabte det.


Løsning :

Placeret ' Directory.Build.targets ', at jeg fandt en mappe op fra min standard 'repos' -mappe i VS-byggestien og kastede den ene mappe op fra mit projekts nuværende katalog, som indeholder :


<Project>
  <PropertyGroup 
      Condition="'$(OS)' == 'Windows\_NT' and
                 '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and
                 '$(SelfContained)' != 'true'"
                  >
    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)dotnetdotnet</RunCommand>
    <RunCommand Condition="'$(PlatformTarget)' == 'x64'">$(ProgramW6432)dotnetdotnet</RunCommand>
  </PropertyGroup>
</Project>


Alt går glat som smør nu ... Så ja det var faktisk en x86/x64 konflikt, bare ikke den samme løsning som alle andre, der har problemer med dette problem. Forhåbentlig hjælper det nogen i fremtiden, spare lidt tid.