2010-12-20 9 views
24

Otrzymuję następujący błąd podczas budowania mojego kodu.

C: \ Program Files (x86) \ MSBuild \ Microsoft.Cpp \ v4.0 \ Microsoft.CppBuild.targets (990,5): ostrzeżenie MSB8012: TargetPath (E: \ Studia \ FWIF \ demola \ ext-libs \ libcommoncpp2-1.6.0 \ w32 \ Debug \ ccgnu2.dll) nie pasuje do wartości właściwości OutputFile programu Linker: g \ CapeCommon14.dll). Może to spowodować niepoprawne zbudowanie twojego projektu. Aby to poprawić, upewnij się, że wartości właściwości $ (OutDir), $ (TargetName) i $ (TargetExt) są zgodne z wartościami podanymi w % (Link.OutputFile).

Mam nadzieję, że ktoś będzie wiedział, co robić.

+0

Czy udało Ci się znaleźć rozwiązanie? – Brown

Odpowiedz

22

Czy zaktualizowałeś projekt do Visual Studio 2010 z poprzedniej wersji? Jeśli tak, to jest to znany problem.

Visual Studio 2010 C++ projektu Upgrade Podręcznik http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx

ostrzeżenia podczas uaktualniania

Oto niektóre z typowych ostrzeżeń, które można uruchomić w trakcie konwersji:

1) Linker katalogu wyjściowego

Jednym z ostrzeżeń pojawiających się podczas aktualizowania aplikacji jest MSB8012: $ (TargetPath) i L wartość nieruchomości outputfile prostowania nie pasuje:

  • MSB8012: $ (TargetExt) (”.dll ') nie pasuje do linkera outputfile wartości nieruchomości 'C: \ foo \ Debug \ MFCActiveX.ocx'('. ocx ") w konfiguracji projektu" Debug | Win32 ". Może to spowodować niepoprawne zbudowanie twojego projektu. Aby to poprawić, upewnij się, że wartość właściwości $ (TargetExt) jest zgodna z wartością określoną w% (Link.OutputFile).

  • MSB8012: $ (TargetPath) ("C: \ foo \ Debug \ MFCActiveX.dll") nie pasuje do wartości właściwości OutputFile Linker "C: \ foo \ Debug \ MFCActiveX.ocx" ("C: \" foo \ Debug \ MFCActiveX.ocx ') w konfiguracji projektu "Debug | Win32". Może to spowodować niepoprawne zbudowanie twojego projektu. Aby to poprawić, upewnij się, że wartość właściwości $ (TargetPath) jest zgodna z wartością określoną w% (Link.OutputFile).

    Link.OutputFile jest wartością zdefiniowaną w Linker -> Ogólne -> Plik wyjściowy na stronie właściwości. Domyślna wartość to $ (OutDir) $ (TargetName) $ (TargetExt), która jest taka sama jak wartość $ (TargetPath). Kiedy jednak konwertujemy aplikację z poprzedniej wersji, nie ma łatwego sposobu konwersji do przeanalizowania linku.OutputFile, aby dowiedzieć się, jakie dokładnie wartości są dla $ (TargetName) i $ (TargetExt), ponieważ różni klienci mogą być sformatowani na różne sposoby. Aby obejść to, postanowiliśmy zachować wartość Linker.OutputFile podczas konwersji. Po konwersji, $ (TargetName) będzie domyślnie $ (ProjectName). $ (TargetExt) będzie domyślnym rozszerzeniem domyślnym dla typu aplikacji: .dll dla biblioteki dynamicznej, .lib dla biblioteki statycznej i .exe dla aplikacji. Wartość Link.OutputFile zostanie zachowana. Ostrzeżenie MSB8012 zostanie wydane w dzienniku konwersji, jeśli Link.OutputFile i $ (TargetPath) nie są takie same. Otrzymasz te same ostrzeżenia podczas budowania aplikacji.
    $ (OutDir), $ (TargetName) i $ (TargetExt) są wyświetlane na stronie właściwości "General", odpowiednio jako "Output Directory", "Target Name", "Target Extension". Możesz ręcznie zmienić wartości tych właściwości, aby nie było już ostrzeżenia.

  • Jeśli twój projekt tworzy bibliotekę importu (łącznik -> zaawansowane -> importuj bibliotekę), może zajść potrzeba zmiany folderu wyjściowego w bibliotece importu, jak również po konwersji, jeśli katalog wyjściowy programu Linker nie jest domyślnym katalogiem wyjściowym. W przeciwnym razie wygenerowana importowana lib może znajdować się w innym katalogu niż wyjściowy linker.

  • Funkcja debugowania.Komenda ma domyślną wartość $ (TargetPath) po konwersji. Może być konieczne wprowadzenie zmian, aby odpowiedni plik wykonywalny został uruchomiony po F5 (debugowanie) lub Ctrl + F5 (uruchamianie bez debugowania).

4

Ten sam problem wystąpił do mnie do debugowania DLL, że chciałem mieć z tyłu „d”, bazowej. Na przykład: foo.dll (Release) ale fooD.dll (Debugowanie). Po dopracowaniu nazwy wyjściowej w ustawieniach Linkera konfiguracji debugowania - pojawia się brzydkie ostrzeżenie MSB8012.

Jedynym rozwiązaniem, które współpracuje z Visual Studio 2010-wydaje się być Postbuild-wydarzenie dla Debug konfiguracji:

@echo off 
echo Copying $(OutDir)$(TargetName)$(TargetExt) as $(TargetName)D$(TargetExt) 
copy /Y $(OutDir)$(TargetName)$(TargetExt) $(OutDir)$(TargetName)D$(TargetExt) 
+18

Zmień Linker -> Ogólne -> Plik wyjściowy na "$ (OutDir) $ (TargetName) $ (TargetExt)".I ustaw General -> Target Name na "$ (ProjectName) D" –

1

I uzyskać ten sam błąd po konwersji ze starego projektu do VS 2010.

Aby to naprawić, utworzyłem pusty projekt tego samego typu (np. .dll, .lib, .exe).
Potem kopiowane swoje wartości domyślne Projektu Propeties do mojego projektu do Output Directory katalogu Pośredniczącą a Output File

4

Zobacz również tutaj Stackoverflow MSB8012. Co było dla mnie przydatne podczas konwersji projektu VS2008 C++ na VS2012: kliknij prawym przyciskiem myszy projekt w eksploratorze rozwiązań, wybierz właściwości, w wyskakującym oknie: właściwości konfiguracyjne, linker, ogólne. Wybierz plik wyjściowy po prawej stronie, w ten sposób pojawi się menu rozwijane, wybierz nieodłączne z domyślnymi lub domyślnymi projektami. Kliknij Zastosuj. Daje to domyślne ustawienie linkera: $ (OutDir) $ (TargetName) $ (TargetExt). Przebuduj projekt, a ostrzeżenie nie powinno już się pojawiać.

+1

To samo co komentarz Nathana Moinvaziriego na odpowiedź Andreasa Spindlera: Zmień Linker -> Ogólne -> Plik wyjściowy na "$ (OutDir) $ (TargetName) $ (TargetExt) ". I ustaw General -> Target Name na "$ (ProjectName) D" –

+0

@NickWestgate Hey Nick ;-) Potwierdzono, że działa dla MSVC 2010. – Michaelangel007

2

Miałem scenariusz, w którym moja nazwa pliku wykonywalnego różniła się od nazwy projektu I chciałem, aby zbudował plik wykonywalny/dll w innym miejscu niż miejsce, w którym znajdował się projekt.

1) Zmień domyślną nazwę projektu na inną. General-> nazwa_obiektu_docelowego
< moja nazwa pliku wykonywalnego>

2) Wyjście do innej lokalizacji, gdzie chcę wykonywalny zbudować. Ogólne-> Numer wyjściowy < Moja nowa lokalizacja jest dostępna tutaj>

3) Zaktualizuj ustawienia Linkera. Linker-> Ogólne nowa wartość: $ (OUTDIR) $ (nazwa_obiektu_docelowego) $ (TargetExt)
ten nabiera nowych ustawień od 1 i 2.

+0

To nie wydaje się odpowiadać na pytanie OP. –

+1

W rzeczywistości krok 3) rozwiązał ten problem dla mnie. – DanielV

Powiązane problemy