zmienna Makra/Środowisko w .sln i plików .vcproj dla Visual Studio

Question

Mam dwa podobne problemy:

a) Mam rozwiązanie, które obejmuje kilka projektów i chcę móc łatwo przełączać lokalizację projektu przez ustawienie niektórych zmienna środowiskowa/makro. Jako przykład tego projektu można znaleźć w \ SolutionDir \ Dir1 \ or \ SolutionDir \ Dir2 \ Więc chcę określić, że powinien on znajdować się w \ SolutionDir \ $ (Var) i po prostu ustawić zmienną.

Czy istnieje jakaś kompilacja w programie Visual Studio, aby to zrobić?

Znam obecnie tylko dwa rozwiązania - edytuj plik .sln ręcznie/programowo, aby znaleźć ten projekt i ustawić poprawną ścieżkę.

Nie mogłem użyć zmiennej środowiskowej w pliku .sln.

b) Mam projekt, który zawiera pliki zasobów (.rc i .h). Chcę móc ustawić ich lokalizację za pomocą innej zmiennej środowiskowej lub makra.

Coś \ ProjectDir \ $ (VAR2) \ resource.rc

znalazłem jakąś obiecującą informacji na temat arkuszy własności, ale Visual Studio nie poszerzyć makr kiedy używam ich w tagu pliku w .vcproj .

Dziękuję za wszelkie pomysły rozwiązania tego problemu.

Pozdrawiam, Victor

Answer 1

myślę, że mają ten sam cel niż: Chcę używać zmiennych środowiskowych, aby zlokalizować kilka projektów w pliku roztwór (.sln) i korzystać z niektórych zmiennych środowiskowych, aby zlokalizować niektórych plików w ramach moich projektów.

znalazłem sposób, aby to zrobić i to działa dobrze dla mnie (z Visual Studio 2005): - edycję pliku .sln za pomocą edytora tekstu i używać zmiennych środowiskowych o następującej składni% MyEnvironmentVariable% - Edycja Pliki .vcproj i zamień ścieżkę do żądanych plików na pewne zmienne, stosując następującą składnię $ (MyEnvironmentVariable).

Nadzieja to pomaga ... Cyrille

Answer 2

Najlepszym sposobem, aby osiągnąć to, co można opisać w punkcie b) jest wykorzystanie zakładek. Sprawdź również ten bardzo similar question.

znalazłem jakąś obiecującą info na arkuszy własności, ale Visual Studio nie rozszerza makr kiedy używam je w tagu pliku w .vcproj.

Nie jestem pewien, jakiej wersji VS używasz. VS2008 pozwala ci zdefiniować na przykład katalog taki jak ten: "$ (OpenCVInclude) \ cxcore \ include". Używam go cały czas. OpenCVInclude to makro zdefiniowane w arkuszu właściwości.

Co do pytania a), myślę, że nie ma "czystego" sposobu robienia tego, co chcesz. Alternatywnie można skonfigurować menedżera konfiguracji:

• Uwzględnij wszystkie projekty w rozwiązaniu.
• Nazwa projektu inaczej, na przykład na podstawie OEM.
• Dla każdego projektu zdefiniuj konfiguracje wersji i debugowania w rozwiązaniu
• W "Build-> Configuration Manager" Możesz zaznaczyć lub odznaczyć kolumnę "Build" dla każdej konfiguracji. Sprawdź "kompilację" dla odpowiedniego projektu.

Answer 3

(a) Cyrille daje przyzwoite rozwiązanie tego, o co prosiłeś. Innym sposobem jest zachowanie twoich zmiennych ustawień w jednym wspólnym miejscu. Zauważ, że to nie zadziała dla plików innych niż msbuild, takich jak * .sln i * .vcproj (do wersji VS 2010).

pliki projektu: ... $ (ChangeableDir) \ foo.cs

Common.targets: ChangeThis ...

Jednakże, I don” Myślę, że to świetny sposób na robienie rzeczy. Jeśli różnice między tym, co budujesz, są dużymi elementami funkcjonalności, powinieneś rozważyć utworzenie gałęzi w systemie kontroli źródła. OTOH, jeśli różnice są niewielkie - np. Ciągi kodowane na sztywno - to prowadzi do twojego drugiego pytania ...

(b) Rodzaj zarządzania zasobami, który opisujesz, to zasadniczo ten sam problem, z którym borykają się ludzie lokujący swój projekt w różnych językach. Na szczęście, bezpośrednie wsparcie jest wbudowany w Visual Studio od 2005. Sprawdź wcześniejsze pytania: Localization in Visual Studio 2008

Answer 4

Wystarczy użyć zmiennej środowiskowej w danej dziedzinie:

OutputDirectory="$(MyEnvVariableName)\Bin" 

Jeden trick jest to, że trzeba ponownie uruchomić Visual Studio IDE za każdym razem, gdy zmieniasz zmienną.

Jest artykuł MSDN właśnie o tym: How to: Use Environment Variables in a Build

Answer 5

Nie jestem pewien, czy jesteś budynku tuż C++ projektów lub jeśli są również budowanie projektów C# \ VB, ale jednym z wielkich rzeczy o Visual Studio jest wszystkie projekty są po prostu projektami MSBuild. Jeśli edytujesz projekt w edytorze tekstu, zobaczysz, że na końcu projektu importuje plik .targets. Jeśli wyszukasz i połączysz się z importami, zauważysz, że prawie wszystkie projekty VS importują Microsoft.Common.Targets. Microsoft.Common.Targets importuje Custom.Before.Microsoft.Common.Targets. Za pomocą tego importu możesz zaimportować własny plik celów za pomocą własnych działań niestandardowych.

Mam na przykład plik docelowy, który ma wspólną właściwość zdefiniowaną we wszystkich projektach rozwiązania i niestandardowe zdarzenie kompilacji pocztowej, które przetwarza na końcu każdego projektu.

Stosując tę ​​metodę rozszerzenia i tworząc niestandardowe konfiguracje w rozwiązaniu oprócz standardowej wersji \ debug, powinieneś być w stanie utworzyć kompleksową konfigurację kompilacji, zgodnie z potrzebą.