Odpowiedzi:
Użyj akcji po kompilacji w swoim projekcie i dodaj polecenia, aby skopiować naruszającą bibliotekę DLL. Czynności po kompilacji są zapisywane jako skrypt wsadowy.
Do katalogu wyjściowego można się odwoływać jako $(OutDir). Katalog projektu jest dostępny jako $(ProjDir). W stosownych przypadkach spróbuj użyć względnych ścieżek, aby można było skopiować lub przenieść folder projektu bez przerywania czynności po kompilacji.
$ (OutDir) okazał się ścieżką względną w VS2013, więc musiałem połączyć to z $ (ProjectDir), aby osiągnąć zamierzony efekt:
xcopy /y /d "$(ProjectDir)External\*.dll" "$(ProjectDir)$(OutDir)"Przy okazji, możesz łatwo debugować skrypty, dodając „echo” na początku i obserwując rozszerzony tekst w oknie wyników kompilacji.
Szczegóły w sekcji komentarzy powyżej nie działały dla mnie (VS 2013) podczas próby skopiowania wyjściowej biblioteki DLL z jednego projektu C ++ do folderu wydania i debugowania innego projektu C # w ramach tego samego rozwiązania.
Musiałem dodać następującą akcję po kompilacji (kliknij prawym przyciskiem myszy projekt, który ma dane wyjściowe .dll), a następnie właściwości -> właściwości konfiguracji -> zdarzenia kompilacji -> zdarzenie po kompilacji -> wiersz poleceń
teraz dodałem te dwie linie, aby skopiować wyjściową bibliotekę dll do dwóch folderów:
xcopy /y $(TargetPath) $(SolutionDir)aeiscontroller\bin\Release
xcopy /y $(TargetPath) $(SolutionDir)aeiscontroller\bin\Debug(Ta odpowiedź dotyczy tylko C #, a nie C ++, przepraszam, że źle przeczytałem oryginalne pytanie)
Przeszedłem już przez piekło DLL w ten sposób. Ostatnim rozwiązaniem było przechowywanie niezarządzanych bibliotek DLL w zarządzanej bibliotece DLL jako zasoby binarne i wyodrębnianie ich do folderu tymczasowego podczas uruchamiania programu i usuwanie ich po usunięciu.
To powinno być częścią .NET lub infrastruktury pinvoke, ponieważ jest tak przydatne .... To sprawia, że udało DLL łatwe do zarządzania, zarówno przy użyciu XCopy lub jako odniesienie projektu w większym rozwiązania Visual Studio. Gdy to zrobisz, nie musisz się martwić wydarzeniami po kompilacji.
AKTUALIZACJA:
Umieściłem kod tutaj w innej odpowiedzi https://stackoverflow.com/a/11038376/364818
Dodaj wbudowaną COPY w pliku project.csproj :
<Project>
...
<Target Name="AfterBuild">
<Copy SourceFiles="$(ProjectDir)..\..\Lib\*.dll" DestinationFolder="$(OutDir)Debug\bin" SkipUnchangedFiles="false" />
<Copy SourceFiles="$(ProjectDir)..\..\Lib\*.dll" DestinationFolder="$(OutDir)Release\bin" SkipUnchangedFiles="false" />
</Target>
</Project>xcopy /y /d "$(ProjectDir)External\*.dll" "$(TargetDir)"Możesz również odwołać się do ścieżki względnej, następny przykład znajdzie bibliotekę DLL w folderze znajdującym się jeden poziom nad folderem projektu. Jeśli masz wiele projektów korzystających z biblioteki DLL w jednym rozwiązaniu, spowoduje to umieszczenie źródła biblioteki DLL we wspólnym obszarze osiągalnym po ustawieniu dowolnego z nich jako projektu startowego.
xcopy /y /d "$(ProjectDir)..\External\*.dll" "$(TargetDir)"Te /ykopie opcja bez potwierdzenia. Te /dkontrole opcja aby sprawdzić, czy plik istnieje w docelowej, a jeśli to robi tylko kopie, czy źródło ma nowszą znacznik czasu niż cel.
Odkryłem, że w co najmniej nowszych wersjach Visual Studio, takich jak VS2109, $(ProjDir)jest niezdefiniowany i musiałem go $(ProjectDir)zamiast tego użyć .
Opuszczenie folderu docelowego w xcopypowinno domyślnie przejść do katalogu wyjściowego. Ważne jest, aby zrozumieć, że $(OutDir)sam rozum nie jest pomocny.
$(OutDir), przynajmniej w najnowszych wersjach programu Visual Studio, jest definiowana jako ścieżka względna do folderu wyjściowego, na przykład bin/x86/Debug. Użycie go samodzielnie jako celu spowoduje utworzenie nowego zestawu folderów, zaczynając od folderu wyjściowego projektu. Np … bin/x86/Debug/bin/x86/Debug. : .
Połączenie go z folderem projektu powinno przenieść Cię we właściwe miejsce. Np $(ProjectDir)$(OutDir). : .
Jednak $(TargetDir)zapewni katalog wyjściowy w jednym kroku.