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 , jest w takim stanie, że mnie raczej nie dziwi, gdy są wprowadzone „małe” zmiany.vNext/5/Core/Whatever it will be
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?
Visual Studio Code, Mac i ASP.NET RC Update1
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Programując z Omnisharp, używasz czegoś do takich refactoringów jak “Move to another file to match class name”?
Comments are closed.