Kompilacja błędów w rozwiązaniu ASP.Net .NET 4.0 + klient google-api-dotnet przy użyciu serwera budowania TeamCity

Question

Przeprowadziliśmy migrację z TFS 2010 do TeamCity i mamy problemy z budowaniem naszego pliku rozwiązania.

Używamy .NET 4.0. Biblioteka Google często powoduje problemy z .NET 4.0 + system.net.http podczas próby jej zbudowania. Udało nam się uzyskać tę konfigurację działającą na TFS (używa MSBuild 4.0) bez błędów.

App.config powinien mieć poprawne assemblybindings:

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
     <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> 
     <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
     <bindingRedirect oldVersion="0.0.0.0-2.6.9.0" newVersion="2.6.9.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
     <bindingRedirect oldVersion="0.0.0.0-2.6.9.0" newVersion="2.6.9.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
     <bindingRedirect oldVersion="0.0.0.0-2.2.28.0" newVersion="2.2.28.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
     <bindingRedirect oldVersion="0.0.0.0-2.2.28.0" newVersion="2.2.28.0" /> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 

Już próbowałem: - korzystać z różnych Runner: Visual Studio, msbuild - Referenced wszystkie dll bezpośrednio (google + system.net.http + itd.) - Wykorzystanie prosto Nuget Pakiet przywrócić na tych bibliotek DLL (przywraca wszystko ok)

błąd kompilacji: ResolveAssemblyReference] C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion .targets (1635, 5): ostrzeżenie MSB3268: Th Początkowe odniesienie "Google.Apis.Auth.PlatformServices, wersja = 1.9.0.26016, Culture = neutral, processorArchitecture = MSIL" nie może zostać rozwiązane, ponieważ ma pośrednią zależność od zestawu ramowego "System.Net.Http, wersja = 2.2 .22.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a ", które nie mogły zostać rozwiązane w aktualnie ukierunkowanym frameworku. ".NETFramework, Version = v4.0". Aby rozwiązać ten problem, usuń odwołanie "Google.Apis.Auth.PlatformServices, Version = 1.9.0.26016, Culture = neutral, processorArchitecture = MSIL" lub ponownie zastosuj swoją aplikację do wersji frameworka, która zawiera "System.Net.Http, Version = 2.2.22.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a ".

następują: [07:58:29] W [MSBuild wyjście] C: \ \ BuildAgent pracy \ dda43f1992063b18 \ Integracja \ CalendarSync \ urządzenia \ kalendarz pomocną \ GoogleCalendarDevice.vb (788,78): błąd BC30009 : Odnośnik wymagany do złożenia "Google.Apis, wersja = 1.9.0.23042, Culture = neutral, PublicKeyToken = null" zawierający zaimplementowany interfejs "Google.Apis.Requests.IDirectResponseSchema". Dodaj jeden do swojego projektu. [C: \ BuildAgent \ work \ dda43f1992063b18 \ Integracje \ CalendarSync \ Severa.Integrations.CalendarSync.vbproj]

Answer 1

Mamy teraz nieoptymalne rozwiązanie tego problemu. MSBuild wyszukuje złą wersję jednego z tych miejsc:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0 

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 4\Packages\Microsoft.Net.Http.2.0.20710.0\lib\net40 

C:\Program Files (x86)\Microsoft Web Tools\Packages\Microsoft.Net.Http.2.0.20710.0\lib\net40 

To jest złe, ponieważ wersja w tych lokalizacjach: 1.0.0.0. Jeśli zastąpić wszystkie te miejsca z wersji 2.2.28 to działa .. Próbowaliśmy następujący:

• Compliation.config dodać Zgromadzenie
• Web.config bindingredirect
• podpowiedzi SLN plików do odpowiednich pakietów.

Niestety nasi agenci TC są we wspólnym środowisku, więc nie możemy zastąpić tych plików we wszystkich tych lokalizacjach.

Wszelkie pomysły?