MSBUILD/csc: Najczystszy sposób postępowania z ostrzeżeniem o mscorlib x64 1607

Próbuję użyć domyślnego systemu projektu VS08SP1 do wywołania kompilacji C# w jawnym trybie x64 (w odróżnieniu od AnyCpu). Kiedy wyraźnie oznaczyć jako moduł x64, otrzymuję:MSBUILD/csc: Najczystszy sposób postępowania z ostrzeżeniem o mscorlib x64 1607

ostrzeżenie CS1607: generacja Assembly - Referenced montaż „mscorlib.dll” skierowany jest inny procesor

Jednym ze sposobów usuwania że jest z a /nowarn:1607. Based on my research, nie ma żadnych problemów w praktyce z tym. Jeśli ktokolwiek może napotkać problem, z którym się zetknął, odpowiedz na to.

Jednak to po prostu źle się dzieje! Więc inne podejście Kiedyś było zrobić /nostdlib+, a następnie dodać <Reference> z zakodowanego na stałe <HintPath> do mscorlib wyraźnie 64 bitowe:

<Reference Include="mscorlib"> 
    <HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath> 
</Reference>

To działa i jest prawdopodobnie lepsza (chyba że ktoś dba wskazać powody, dla których poprzednie podejście jest lepsze), ale czy ktoś może potwierdzić, że jest to odpowiednie rozwiązanie, mając nadzieję, że przytacza coś autorskiego?

Źródło

2009-08-13 Ruben Bartelink

Napotykam ten sam problem. Byłby zainteresowany rozwiązaniem. Dzięki. – decasteljau

Znalazłem, zmieniając strukturę docelową mojego projektu na .NET Framework 4, eliminując ostrzeżenie.

Źródło

2011-04-13 17:47:39

+1 Ale przejście do innego CLR i VS jest oszukiwaniem: P (Serioulsy, dziękuję za poświęcenie czasu na odpowiedź) –

Ostateczne przyjęcie - podczas gdy to nie odpowiada na rzeczywiste pytanie, jest to rozwiązanie, którego faktycznie używałem, a ja zgadnij, że to prawie idiomatyczna "odpowiedź" w tym ekosystemie ... –

To nie jest rozwiązanie problemu w żaden sposób. Być może pracował dla ciebie Todd, ale wiele projektów nie może być po prostu zmienionych, by celować w inne ramy. – xxbbcc

Uważam, że twoja druga opcja (jednoznaczne odwołanie z /nostdlib+) jest lepsza, ponieważ nie spowoduje to zignorowania tego ostrzeżenia, jeśli miałbyś odwoływać się do innych złożeń nie zbudowanych na tej samej platformie.

Źródło

2010-11-03 16:08:09

+1 wnikliwe (po raz pierwszy nie byłem pewien). Będę wstrzymywał się, aby zaakceptować moją wybraną ocenę: P (Poważnie: jestem zainteresowany słyszeniem jakichkolwiek negatywów z mojego drugiego podejścia - można by pomyśleć, że byłoby to domyślne przez VS, jeśli nie ma wady). Jednak myślę, że z perspektywy 'msbuild' ma to sens, a' csc' nie powinien mieć całej tej polityki wbudowanej bezpośrednio w narzędzie –

Nie mogę wymyślić żadnych wad, chyba że kompilujesz się na pudełku x86 to może nie mieć zespołu na tej ścieżce. –

jeśli chodzi o msbuild (naprawdę budowanie zespołu), moją preferencją byłoby uruchamianie każdej platformy zbudowanej na tej platformie. –

In this blog znalazłem propozycję, która jest zbyt długa, aby skopiować go w całości tutaj, ale w skrócie idea może być opisana z podsumowaniem adaptacją this comment:

W pliku projektu, można zdefiniować zmienną niestandardową w sekcji PropertyGroup dla każdej konfiguracji kompilacji. Przykład:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'"> 
    <MyCustomPath>C:\Windows\Microsoft.NET\Framework64</MyCustomPath> 
</PropertyGroup>

Wystarczy dodać znacznik, taki jak

<Reference Include="System.Data"> 
    <HintPath>$(MyCustomPath)</HintPath> 
</Reference>

a następnie za pomocą makra do określenia ścieżki referencyjnej. Możesz zdefiniować MyCustomPath w innym miejscu dla różnych konfiguracji kompilacji (platforma i/lub debugowanie/wydanie).
Problem nie istnieje, jeśli MS będzie obsługiwać to w interfejsie VS, ale do tego czasu będzie działać. Używam tej techniki do odwoływania się do różnych wersji tych samych zestawów w moich debugujących kompilacjach wersji &. Działa świetnie!

W powyższym wydaniu odzyskałem tag, który został utracony w komentarzarium źródłowym i zmieniono brzmienie, aby było nieco bardziej szczegółowe.

Dodatkowym ciekawy kawałek z same blog:

Istnieje kilka innych sposobów, aby to zrobić, ale one także wymagać jednego ręcznie edytować pliki projektu.Jednym ze sposobów jest określenie warunków dla sekcji PropertyGroup. To pytanie o numerze StackOverflow podkreśla użycie warunków.

Źródło

2012-02-03 21:03:42

+1 W moim scenariuszu, tak naprawdę nie potrzebuję tego tecnique - zawsze chcę 'x64'. Nadal pozostawiają pytanie nieakceptowanym - chciałbym wiedzieć, co Microsoft zaleca jako sposób postępowania z błędem wbudowanym (bez konieczności tolerowania ich okropnego oprogramowania forum: P) –

W moim przypadku miałem to ostrzeżenie, ponieważ miałem mieszankę projektów x86 i x64 w moim rozwiązaniu. Jeśli utworzę konfiguracje kompilacji x86 we wszystkich moich projektach, a docelowy dla kompilacji, ostrzeżenia znikną. Jeśli jednak chciałbym kierować na x64 we wszystkich, uważam, że musiałbym przebudować projekt (lub skorzystać z porady powyżej), aby przerobić je na framework x64.

Źródło

2014-08-29 14:23:50

MSBUILD/csc: Najczystszy sposób postępowania z ostrzeżeniem o mscorlib x64 1607

Odpowiedz

Powiązane problemy