Chciałbym Was przeprowadzić przez proces skompilowania, uruchomienia i debuggowania .NET Core - czyli wersji open source środowiska .NET. Bez zbędnych wstępów przejdźmy do odpowiedzi na proste pytanie... Po co?

Czas naprawdę "szybko leci". Prawie jak wczoraj pamiętam udział w konferencji .NET Developer Days 2015, a tutaj już na poważnie rozkręciła się organizacja tegorocznego wydarzenia. Było ciekawie, więc z dużym zainteresowaniem śledziłem doniesienia organizatorów na temat tego, co szykują w tym roku.

A właściwe o tym, że właśnie Ty masz talent! I nie ważne co Ci mówią inni, co Ci mówi świat, ani tym bardziej - co sam o tym myślisz. Skąd taka pewność? Bo tak. Stary bardzo nie jestem, ale coś tam już wiem (...).

Nie będę oryginalny pisząc, że nie jestem oryginalny i zbliżający się koniec konkursu "Daj się poznać" odnotuję krótkim podsumowaniem. A zatem oto i podsumowanie. Celem mojego udziału nie było skończenie projektu, bo realnie patrząc, wiedziałem, że się z tym...

W poprzednich częściach znęcałem się nad biblioteką ClrMd i zawartym w niej niedopatrzeniu – poważnym problemie z deadlockiem. Korzystając, że jest to Open Source dostępny na GitHubie, czuję się w obowiązku spróbować dostarczyć oficjalną poprawkę. A to świetna okazja do napisania artykuliku o tym, jak to formalnie przeprowadzić.

Tak jak pisałem w jednym z poprzednich postów, zdecydowałem się użyć Paket do zarządzania zależnościami w projekcie. Dlaczego? Ponieważ poza zależnościami NuGetowymi, mam jedną dużą, niestandardową - standalone binarki bazy neo4j. Tak jak pisałem, Paket poza źródłami z serwerów NuGetowych potrafi korzystać ze źródeł Gita oraz po prostu zasobów dostępnych przez HTTP.

W poprzednim poście posłużyłem się następującym kodem, mającym wczytać plik ze zrzutem pamięci i następnie załadować odpowiednią wersję pliku mscordacwks.dll. Niestety, jak już wspomniałem, ten kod umieszczony w aplikacji WPF powoduje jej zawieszenie - na wywołaniu CreateRuntime() interfejs przestaje odpowiadać i możemy czekać tak w nieskończoność.

Projekt MemoryVisualizera toczy się w kilku wątkach, ale jak na razie dość mało poświęciłem jednemu z najważniejszych - analizy pamięci. Planuję bardziej rozbudowany post o tym jak można się do pamięci dobrać i co tak naprawdę siedzi pod spodem. Na razie jednak jako "zajawkę...

W poprzedniej części wątku WPFowego projektu MemoryVisualizer skupiłem się na przypomnieniu, czym jest i jak implementować komendę (interfejs ICommand) w C#. Dla przypomnienia, napisałem ogólne rozwiązanie, któremu podaje się odpowiednie metody, dzięki czemu jest ca...

Opis projektu MemoryVisualizera toczy się w kilku wątkach. Jednym z nich jest moja przygoda z F# w kontekście WPF. Po pierwszej części, w której w ogólności opisywałem jak możemy “pożenić” WPF z F#, pora kolejne kroki. Ale wcześniej potrzebne nam będzie krótkie przypomnienie z WPF w C#.