String selectCost = "select Cost from OS where idOS='" + Value1 + "'";
double Summa = Convert.ToDouble(selectCost) *
Convert.ToDouble(count);
Partial declarations of 'RanksWindow' must not specify different base classes
RanksWindow , один наследуется от BaseWindow, а второй - чего-то ещё, наверное Window. А нужно указать только одного родителя. И ещё выучить английский, или хотя бы научиться пользоваться переводчиком. И самое главное - культурно писать. 
const foo = (arg: number) => { /* do something with number type */ };<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<DebugType>none</DebugType>
<DebugSymbols>false</DebugSymbols>
</PropertyGroup>
Есть мысли перейти на селфхостинг, однако есть опасения, что мировой опыт отвергает такой подход
мопед не мойно:
Сначала мы пошли по простому пути: прикрутили IIS, создали ASP.NET-приложение с фреймворком ASP.NET Web API и начали пилить бизнес-логику. Быстро стало понятно, что вся эта конструкция не держит больше 500-700 запросов в секунду. Как бы мы ни заклинали IIS, ни подкручивали 100500 параметров, проблема не решалась. И совсем доставало, что залезть внутрь IIS нет возможности, а значит полного контроля над ситуацией нам не добиться. IIS — пресловутый черный ящик, в котором тяжело что-то кардинально изменить.
Тогда мы попробовали сервер проекта Katana (реализация OWIN-инфраструктуры от Microsoft). Katana — проект с открытым исходным кодом, поэтому можно было увидеть внутренности. К тому же, у Web API есть поддержка OWIN, а значит, сильно менять код не придется. Katana предоставляет возможность работать как с IIS, так и с их простым сервером, написанным на основе .NET-овского HttpListener. Именно его мы и взяли. Результат порадовал: теперь сервер держал около 2000 запросов в секунду, а ASP.NET приложение трансформировалось в Windows-сервис.
Однако нагрузка на сервера увеличивалась, пилились новые фичи. Становилось понятно, что и этот вариант нас тоже не устраивает. Тогда мы пошли на кардинальные меры: от всей Катаны остался только HttpListener с небольшой обвязкой для асинхронности, от Web API не осталось ничего, то есть приложение стало полностью заточено под HTTP-запросы для биддера. В результате сервер стал способен обрабатывать до 9000 запросов в секунду. Вывод прост: вся OWIN- и Web API-обвязка оказывает критическое влияние на высокопроизводительные приложения. Хотите быстрее — пишите проще и неуниверсально. (Это не говорит о том, что внутри приложения должен быть ядерный говнокод. У нас всё модульно, вполне расширяемо: DI, паттерны и всё такое)
1) Нужен ли ментор? Так ли его присутствие помогает прогрессировать?
2) Стоит ли сразу "прыгнуть из лодку, чтобы научиться плавать" и пытаться написать какой нибудь простой игровой движок, бота по туториалам, где гуглишь непонятные части и изучаешь темы?
Есть небольшой опыт общения с плюсиками в универе и пет-проектах.
... 10+ летней давности
