Wspóldzielenie plików w parallels i debugowanie dotnet

Podczas przygotowywania się do sesji (nagranie) na var Sovia = new Tech(); natrafiliśmy na problem wydawałoby się z dotnet core. Problem był dziwny i dotyczył debugowania. To znaczy, po stworzeniu projektu, otwarciu go w VS Code, poczekaniu na załadowanie się narzędzi i wygenerowania folderu .vscode nie mogliśmy debugować aplikacji. Nasza konfiguracja była dość prosta, Windows jako maszyna wirtualna na macu – wszystko za pomocą parallels. Idea prezentacji była taka by Bojan pisał całość na Windows a potem się przerzucił na maca i pokazał, że tam też to śmiga.

Problem braku możliwości debugowania testowaliśmy na różne sposoby, w którymś momencie Bojan nawet przetestował 2-3 edycje VS Code wstecz jak i edycję Insiders. Problem wciąż istniał. Plusem było to, że znaleźliśmy workaround. Po utworzeniu katalogu .vscode należało zamknąć folder i otworzyć go ponownie w VS Code i mogliśmy już aplikację debugować.

Sytuacja była dość dziwna, niby Windows 10, niby najnowszy VS Code oraz dotnet core a jednak… nie działa. Co innego na macu… tam śmigało, jak należy. Bojan próbował wszystkiego i dalej nic. Nawet przygotowaliśmy wersję prezentacji, w której mówię: restart driven developemnt, Microsoft way. Czyli naprawdę nie potrafiliśmy tego obejść.

Do wieczora, kiedy to wracając już tramwajem do hotelu, zadałem pytanie jak Bojan odpala to samo rozwiązanie tworzone na Windows na Macu – w sensie, jak udostępnia kod który piszemy. Wspomniał, że wykorzystuje folder sharing i nie wiem czemu, ale zapaliła mi się gwiazdka w głowie. Skoro rozwiązanie działa na macu, działa po ponownym otworzeniu VS Code, to znaczy, że gdzieś musi być coś nie tak z plikami – jakiś lock czy coś podobnego założone przez jakąś usługę. Nie wiedziałem co dokładnie ale… wiedziałem, że to jest możliwe. Na odchodnym powiedziałem do Bojana by sprawdził tworzenie rozwiązania w folderze innym niż tej współdzielony. Wieczorem dostałem maila: działa.

Okazało się, że to nie była wina ani VS Code, ani dotnet core, ani Omnisharpa, a parallels który blokował lub nakładał jakiegoś locka na folder, przez co mieliśmy kłopot z przeprocesowaniem plików – to tak dokładnie wyglądało, że pliki w .vscode które zostały wygenerowane to nie był jeszcze plikami ostatecznymi. Tak jakby jakaś usługa gdzieś blokowała aktualizację pliku po tym jak został utworzony. Co dokładnie było nie tak, dalej pozostaje tajemnicą ;) ale jest z tego dobra lekcja, która jest znana i stara jak świat: odizoluj problem.

Ja sądziłem, że my cały czas działamy w odizolowanym środowisku, ale przez ten folder współdzielony tak nie było. Samo sprawdzenie tego w innej lokalizacji by zaoszczędziło nam dobre 1,5-2h pracy.

Dlatego warto pamiętać:

• Współdzielone foldery nie są takie dobre ;)
• Należy zawsze odizolować problem

Cieszę się, że to nie był bug dotnet core jak też VS Code czy Omnisharp. Lubię te projekty, mimo że nie daje tego po sobie poznać :)