Pytanie MSBuild nie zbiera referencji do przywoływanego projektu


W tej chwili wpadłem na dziwną sytuację z MSBuildem. Jest rozwiązanie, które ma trzy projekty: LibX, LibY i Exe. Exe wskazuje na LibX. LibX z kolei odnosi się do LibY, ma pewne pliki treści, a także odniesienia do biblioteki innej firmy (kilka gotowych zestawów zainstalowanych zarówno w GAC, jak i lokalnym folderze lib). Zewnętrzna biblioteka jest oznaczona jako "Kopiuj lokalnie" ("prywatne") i pojawia się w wynikach projektu LibX, tak jak robią to pliki wyjściowe LibY i pliki zawartości LibX. Teraz dane wyjściowe projektu Exe zawierają dane wyjściowe projektu LibX, pliki zawartości projektu LibX, dane wyjściowe projektu LibY (pochodzące z biblioteki LibX), ale brak zestawów bibliotek innych firm.

Teraz pracowałem nad tym, odwołując się do biblioteki innej firmy bezpośrednio w projekcie Exe, ale nie uważam, że jest to "właściwe" rozwiązanie.

Ktoś miał ten problem wcześniej?


14
2017-09-26 01:14


pochodzenie


jakiekolwiek ostateczne rozwiązanie z pełnym tekstem kodu źródłowego działającym na jego temat? - Kiquenet


Odpowiedzi:


Tak, też miałem ten problem. Chociaż chciałbym powiedzieć inaczej, uważam, że musisz uwzględnić wszystkie przejściowe zależności jako referencje w pliku kompilacji.


3
2017-09-26 15:28





Występuje różnica w zachowaniu podczas budowania za pomocą MSBuild (np. Wiersza poleceń, TFS Build i innych narzędzi) w porównaniu do budowania z Visual Studio. Odwołania pomocnicze nie są zawarte w zmiennej referencyjnej wysyłanej do zadań kompilacji MSBuild.

MSBuild udostępnia kilka punktów rozszerzeń, aby zmienić sposób rozwiązywania referencji. Z powodzeniem użyłem AfterResolveReference do rozwiązania tego problemu w przypadku niektórych moich projektów - Napisałem więcej informacji o tle na moim blogu.

Rozwiązaniem jest dodanie następującego kodu do plików vbproj lub csproj

  <Target Name="AfterResolveReferences">
    <!-- Redefine referencepath to add dependencyies-->
    <ItemGroup>
     <ReferencePath Include="@(ReferenceDependencyPaths)">
     </ReferencePath>
    </ItemGroup> 
  </Target>

Microsoft oświadczył, że to nie będzie naprawić Połączyć


12
2018-02-17 12:02



Doskonały. Jest to w rzeczywistości lepsze rozwiązanie tego problemu. - the.fabricio


Możesz przejść do pliku Microsoft.CSharp.targets lub Microsoft.VisualBasic.targets (znajdującego się w katalogu framework, zazwyczaj C: \ Windows \ Microsoft.NET \ Framework \ v3.5) i zmodyfikować parametry zadania csc lub vbc na zawierają dodatkowe zależności referencyjne. W pliku (cele VB, linia 166, obiekty C #, linia 164) zmień: \

References="@(ReferencePath)"

do

References="@(ReferencePath);@(ReferenceDependencyPaths)"

Może to powodować inne problemy w zależności od tego, jak skomplikowane są rzeczy i może odgrywać sztuczki z kompilatorem inProc programu Visual Studio, ale jest to jedyny sposób, aby to zrobić w MSBuild, który znalazłem.


4
2017-10-02 20:27



Na początku nie miało to żadnego skutku, ale potem odkryłem, że (przynajmniej w Framework\v4.0.30319) linia ta występuje dwukrotnie w każdym z nich .targets akta. - CoderDennis


odpowiedź Josos prawie dla mnie zadziałała; Podczas próby wykonania programu Visual Studio wystąpił błąd:

Wystąpił problem podczas próby ustawienia parametru "References" dla kompilatora wewnątrz procesora IDE. Błąd HRESULT E_FAIL został zwrócony z połączenia do komponentu COM

Rozwiązaniem mojego problemu było postawienie warunku w ItemGroup, na przykład:

<Target Name="AfterResolveReferences">
  <!-- Redefine referencepath to add dependencies-->
  <ItemGroup Condition=" '$(BuildingInsideVisualStudio)' != 'true' ">
    <ReferencePath Include="@(ReferenceDependencyPaths)"></ReferencePath>
  </ItemGroup>
</Target>

To spowodowało, że Visual Studio całkowicie zignorowało zmianę referencyjną, a kompilacja działa dobrze lokalnie i na serwerze kompilacji.


3
2018-02-01 22:40





Połączyłem Alexa Yakunina rozwiązanie z takim, który będzie również skopiować lokalne biblioteki dll.


2
2018-05-02 06:54



Użyłem rozwiązania Alexa Yakunina. Sprawdziło się doskonale dla mnie. - Matt Varblow


Metoda AfterResolveReferences kończy się niepowodzeniem, jeśli masz skierowany wykres, który nie jest drzewem z "próbą wdrożenia różnych kopii biblioteki dll". (por. Jak skonfigurować msbuild / MSVC do wdrażania zależnych plików zależnych zestawów)


0
2018-03-16 18:38