Foggy Finder

Дело было в том, что везде прежние названия форм в коде, нужно было заменить на новые.
Всем спасибо.

json2csharp.com

public class Section
{
    public string type { get; set; }
    public string group { get; set; }
    public int count { get; set; }
    public string name { get; set; }
    public string displaytype { get; set; }
    public List<object> data { get; set; }
}

public class RootObject
{
    public string xmlns { get; set; }
    public string status { get; set; }
    public string version { get; set; }
    public int webplayer { get; set; }
    public string responsetype { get; set; }
    public List<Section> sections { get; set; }
}

Несмотря на то, что эти инструменты созданы для решения одних и тех же проблем, делают они это по-разному, как под капотом, так и в плане предлагаемых абстракций. Потому нельзя сказать что async/await в C# - это "просто обертка над горутинами".

Горутины в Go - это концепция stackful coroutines (под капотом) + CSP (в абстракциях). Каждый раз, когда мы создаём горутину, под неё выделяется отдельный стек вызовов для её собственных нужд. При этом, когда происходит паника, то stack unwinding (размотка стека вызовов) происходит только в пределах этой горутины и не покидает границ её стека. Стек горутины полностью отвязан от стека её создания/вызова, потому горутина не может возвращать результат. Любое общение между горутинами выполняется либо посредством каналов, либо какой-то общей памяти.

async/await в C# (то есть, Task'и) - это концепция stackless coroutines (под капотом) + futures (в абстракциях). Код с async/await'ами компилятор превращает в определенную стэйт-машину с yield point'ами. У них нет отдельного стека, они выполняются в том же стеке что и вызывающий их код. Соотвественно, есть возможность словить exception'ы (аналог panic'и) возникающие внутри асинхронного Task'а прямо в запускающем его коде. Так как выполнение идёт на том же стеке - Task нормально может возвращать результат и мы его можем считать в вызывающем коде без дополнительных примитивов/инструментов.

При этом, если мы запустим Go с GOMAXPROCS=1, то мы получим однопоточный асинхронный код в Go (по умолчанию он многопоточный). Также и в C# мы можем выполнять Task'и как на одном потоке, так и на thread pool, получая аналогичные Go гарантии рантайма.

С точки зрения абстракций/использования - это уже вкусовщина. Кому как больше нравится. У futures лучше дизайн в плане composability (их эргономичнее join'ить и select'ить), но они вынуждают писать везде async и await. У горутин надо постоянно городить чехарду с синхронизацией (попробуйте сделать аналог await для произвольной горутины), но если эту чехарду прятать под капот (как обычно и делают), то код вообще выглядит полностью синхронным и программисты радуются.

await только подписывается на результат awaitable (в нашем случае Task). И то будет ли выполнятся этот не зависит от await т.е. от тех кто его может ждать. т.е. ответ - Да, Notify() будет себе часами молотить. Если внутри будет ошибка, то лучше подписаться на результат и скипнуть ошибку. Notify().ContinueWith(t=> { var x = t.Exception; ... });

Task.Run(async () =>
Так делать не стоит, это ошибка, которую часто совершают. 'async => ()' это уже стейт-машина которая запускается вызовом, ее не надо шедулить через таски.
Правильный пример:

new Func<Task>(async =>  {
    try
    {
        await _notification.Notify();
    } catch(Exception ex) {
        // TODO: Логируем исключение
    }
}).Invoke();

Но опять же это всё не нужно в текущей задаче, можно вызвать ContinueWith.

Все таки был неправильный HWnd указан.
Для SendMessage нужно указывать HWnd не самого окна, а именно HWnd дочернего поля, куда нужно послать нажатие клавиши.

Авиакассу по продаже билетов. Отдельные таблицы бд для рейсов, билетов, пассажиров и т.д. И «вишенкой на торте» слелать типа статистика по продажам за месяц.

Чтобы не завалить проект - начинать надо с описания проекта - тобишь технического задания. И дальше уже на его основе определять что вам нужно и как это сделать.

P.S. В VS2017 немало языков программирования. И платформ. Вот начните хотя бы с этого.

У меня нет вышки - я бросил ЛЭТИ на третьем курсе. Сейчас я руководитель IT отдела крупной организации в СПБ, Senior Software Developer и Solution Architect. Делайте выводы

Ни разу не видел в требованиях комании наличие диплома, в вакансиях пишут перечень технологий, зная которые вас могут взять, от вас требется только это. Поэтому определитесь на какую должность вы хотите устроится, на такую и идите учиться, главное нужно помнить что поступаете вы не ради диплома, с дипломом и без знаний вас не возьмут.

У меня например диплом електрика. Как правило специальность в дипломе не играет решающей роли при трудоустройстве в ИТ, играют роль специфические знания. Но, сильно зависит от специализации в ИТ, например на фронта редко в институте можно получить актуальные знания и поэтому тут все зависит от способности постоянно учиться самому, а на проекты вроде автопилотов часто математики выглядят намного убедительнее людей с ИТ кафедры.

Можно ли на WPF создавать самостоятельные приложения для частного использования?
Эти приложения могут индивидуально писаться под заказ как сайты к примеру?

А кто запрещает?

Что еще нужно, чтобы сделать цельное приложение?

А что это "цельное" приложение должно делать?...