2009-04-01 6 views
5

Używam następujące stanowisko budować działań w projekcie, aby połączyć lib do mojej aplikacji:VS .NET: post zbudować zdarzeń dla „Primary Output z <myProject>” w projekcie instalatora

IF $(ConfigurationName) == Debug GOTO end 
cp $(TargetPath) $(TargetDir)app_unmerged.exe 
del $(TargetPath) 
"C:\Program Files\Microsoft\ILMerge\ilmerge.exe" /internalize $(TargetDir)MyApp_unmerged.exe $(TargetDir)someLib.dll /out:$(TargetDir)myApp.exe 
del $(TargetDir)myApp_unmerged.exe $(TargetDir)someLib.dll 
:end 

to działa w porządku. Teraz mam projekt instalatora i dodałem wynik projektu. Spodziewam się, że użyte zostanie "Wyjście pierwotne z", tj. Exe in/bin/Release. Ale faktycznie zamiast /bin/release/myApp.exe, używany jest /obj/release/myApp.exe.

Czy ktoś wie, czy mogę zmienić to zachowanie i użyć wyjścia w/bin/release dla projektu instalatora? Dzięki.

Odpowiedz

1

Wygląda na to, że nie istnieje prawdziwe rozwiązanie tego problemu, ale istnieje obejście tego problemu. I stworzył bilet na Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=428898

Microsoftu anwser:

Cześć,

W celu realizacji tych działań po budować, trzeba będzie umieścić je w pliku wsadowym, a następnie dodać jest właściwa polecenie wywołania pliku wsadowego w oknie dialogowym zdarzenia budowania postu. Widzę, że istnieje kilka instancji w skrypcie z odniesieniami do wielu zmiennych Visual Studio. Ponieważ nie ujawniamy tych zmiennych jako zmiennych środowiskowych, trzeba je przekazać jako parametry do pliku wsadowego.

Mam nadzieję, że to pomoże!

Cukierki Chiang Program Manager - Visual Studio

+0

Ten link nie wydaje się być publiczny ("Nie można znaleźć treści, której zażądałeś, lub nie masz uprawnień, aby ją wyświetlić."). Ponieważ reszta z nas nie może go wyświetlić, należy usunąć go z odpowiedzi. – mhenry1384

1

Pliki umieszczam jawnie, co oznacza, że ​​zamiast nakazać projektowi instalacji korzystanie z pierwotnej zawartości, jawnie umieszczam plik .exe/.dll.
To działa całkiem nieźle, mam kontrolę nad tym, który plik zostanie wprowadzony i ścieżkami względnymi dla użytkownika projektu instalacji, więc projekt instalacji może być używany na innych komputerach.

+1

Chociaż działałoby to kosztem braku możliwości pracy z różnymi konfiguracjami kompilacji, ponieważ lokalizacja pliku jest różna dla różnych konfiguracji. W tej chwili mam konfigurację Debug, Release i EvaluationRelease. – phatoni

+0

Wiem, instalujemy tylko wersję. BTW, większość projektów przenosi się do Wix3, musisz najpierw ciężko pracować, ale masz kontrolę nad wszystkim. –

2

rozwiązać ten problem stosuje ILMerge w/folderu obj, to moja konfiguracja zdarzeń post-build:

KOPIA $ (ProjectDir) obj \ $ (PlatformName) \ $ (ConfigurationName) \ $ (TargetFileName) $ (TargetDir) temp.exe $ (solutionDir) \ lib \ ilmerge/wildcards/t: exe/out: "$ (ProjectDir) obj \ $ (nazwa platformy) \ $ (ConfigurationName) \ $ (TargetFileName) "" $ (TargetDir) temp.exe "" $ (TargetDir) log4net.dll "" $ (TargetDir) other.dll " DEL $ (TargetDir) temp.exe