Dotnet niepokorny

D

Siedzisz sobie spokojnie w pracy. Piszesz nowy super-feature, w nowym super-projekcie. Palce biagają po klawiaturze jak małe Usain Bolt’y, wszystko idzie jak z płatka.

Aż nagle wpada do pokoju timlider i mówi – „Fajny ten Twój super-projekt. Zrób mu joba jenkinsowego”.

Mówisz sobie – „Nie trać rezonu”! Trzeba brać się do roboty!

 

Do dzieła!

Tworzysz nowy projekt na panelu w jenkinsie, bierzesz się za napisanie pliku projektu jenkinsowego.

To nic, że Twoja aplikacja jest napisana w dotNET core 2.0, przecież to już dojrzała technologia!

Deklarujesz wszystkie potrzebne ścieżki, tworzysz target’y nazewniczo-kompilująco-clean’ujące. Przychodzi czas na gwóźdź programu:

[code lang=”xml” wraplines=”true”] <Exec Command=”dotnet publish „$(SolutionFile)” -c $(Configuration) -o „$(dirCreated)””/>
[/code]

Wiadomo: dotnet publish „<ścieżka pliku solucji>” -c <konfiguracja> -o <katalog decelowy>

Wszystko ładnie, pięknie i świetliście. Jenkins buduje solucję, odpala co trzeba, kopiuje, gra, tańczy i śpiewa. Cały w skowronkach przechodzisz do katalogu docelowego, odpalasz swój projekcik iiiiii…

 

System.Data.Entity.Core.MetadataException: Unable to load the specified metadata resource

 

…ale jak to?!

Przecież działało!

Ja to zrobiłem, więc nie może NIE działać!

 

…a w bebechach bałagan

Mam dla Ciebie, drogi Czytelniku, niespodziankę.

Otóż okazuje się, że w przypadku projektu dotnet Core’owego, w którym mamy referencję do projektu .NET Framework’owego z Entity Frameworkiem i .edmx’em, komendy dotnet publish, dotnet run, skutkują m.in. nie osadzeniem metadanych w wynikowych bibliotekach (źródeł np. .msl, .csdl, .ssdl).

Okazuje się, że jest to bug w MSBuild, nad którym Microsoft jeszcze nie pracuje (jest zgłoszony ticket). Po prostu nie ma odpowiednich, odpowiedzialnych za to bibliotek w MSBuildzie. W Visual Studio 2017 są, dlatego budując za jego pomocą to działa.

No i co teraz? Budowane ciężką pracą, okraszone potem i łzami, chwała i celebryctwo pójdą w niepamięć?

 

Naokoło

Czas zatem na workaround:

  1. Można sobie na boku zbudować projekt w .Net Frameworku z biblioteką EntityFramework (która będzie zawierać potrzebne metadane) i gdzieś na boku przechować potrzebne dll’ki, a po zbudowaniu projektu z komendy dotnet publish/run, podmienić je. Przyznacie, że to jest śliskie rozwiązanie, prawda?
  2. Najlepiej po prostu odpalić msbuild.exe, podać kilka parametrów i po sprawie. Tak tradycyjnie:

[code lang=”xml” wraplines=”true”] „C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe” WebApplication1\WebApplication1.csproj
/p:DeployOnBuild=true /p:Configuration=Release /p:WebPublishMethod=Package /p:DeployTarget=WebPublish /p:PackageAsSingleFile=true
/p:DeployIisAppPath=”Default Web Site” /p:SolutionDir=”.” /p:DesktopBuildPackageLocation=”c:\tmp\WebApplication1.zip”
[/code]

Oczywiście wszystkie dodatkowe ustawienia ustawiacie wedle własnego uznania i potrzeby. Natomiast to jak na razie najlepsze obejście wyżej opisanego problemu.

Mam nadzieję, że problem zostanie wkrótce rozwiązany i będziemy mogli budować swoje dotnet core’owe projekty „prawilnie”, bez wydziwiania.

No to do dzieła Zuchy!
Patryk.

 

PS.

Pozostaw komentarz, zapisz się do newslettera! Jesteś jedyną osobą mogącą dać mi znać, co robię ok, a co nie tak.



About the author

Add comment

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi