Nie wiem zbytnio jak mam to zakwalifikować gdyż mam nadzieję, że to jest tymczasowe. Przygotowując dema to mojej ostatniej prezentacji chciałem pokazać Visual Studio Code ( oficjalna strona) wraz z OmniSharp na OSX – jak to działa, jak można mieć intellisense itp.

Jednak po zainstalowaniu świeżo najnowszej paczki intellisense nie chciało śmigać. Pół biedy, dostałem info, że OmniSharp nie może znaleźć dnx. Ale jak to? Przecież z command line jestem wstanie wszystko odpalić to czemu nagle VS Code z OmniSharp ma z tym problem?

Zarobiłem więc prostą rzecz, napisałem:

where dnx

i odkryłem, że dnx zamiast siedzieć w katalogu:

~/.dnx/runtimes/

siedzi w

/usr/local/lib/dnx/runtimes/

Co? Dlaczego? A no, dlatego bo tak. Szczerze to ASP.NET vNext/5/Core/Whatever it will be, jest w takim stanie, że mnie raczej nie dziwi, gdy są wprowadzone „małe” zmiany.

U mnie, rozwiązaniem okazało się z linkowanie jednego folderu do drugiego. Jako, że to co siedziało w .dnx mnie już nie interesuje (bo zakładam, że taka jest intencja MS), to po prostu:

# runtimes folder istnieje ale jest pusty (tak było u mnie)
ln -s /usr/local/lib/dnx/runtimes/* ~/.dnx/runtimes/

# runtimes folder nie istnieje
ln -s  /usr/local/lib/dnx/runtimes/ ~/.dnx/runtimes/

Od tej pory mi VS Code zaczął śmigać z OmniSharp.

Może więc ten hack się komuś przyda?

2 KOMENTARZE

ZOSTAW KOMENTARZ