Алексей Немиро: То, что вы привели - это не .Net 2.0 код, а .Net 4.6, как вы сами и написали, что нужна 6.0 версия языка. Естественно версии .Net имеют различия, и очень большие, вы еще от 2.0 проектов Linq потребуйте или асинхронность. Бардака никакого нет, это в любом языке(тяжело собрать программу С++14, компилятором который его не поддерживает). Проблема в том, что даже назначив целевую среду .Net 2.0, VS будет использовать компилятор последней версии. Выше приведенный код, спокойно собирается в VS, но не собирается если непосредственно вызвать компилятор 2.0.
Алексей Немиро: Какой прочий зоопарк? Версия .Net и определяет версию C#. Вы уже запутались сами. ISO/ECMA не определяют спецификацию языка, скажем как это выглядит в случае C++. Спецификацию языка сейчас определяет только MS, а не ISO/ECMA, так как C# и .Net развивается только MS, а остальные только догоняют. Так и не понял про, что это: "Всякие фишки добавляемые в Visual Studio - это тоже серьезная проблема. Например из последнего, интерполированные строки ($"hello {username}") можно использовать в коде любой версии C#, но только в Visual Studio 2015, со всеми вытекающими последствиями". Какие последствия? Какие фишки? То, что с новыми возможностями языка нормально работают лишь последние версии VS, так это нормально, это фактически зависит от того, что в IntelliSence студии заложено.
Алексей Немиро: "но только в Visual Studio 2015, со всеми вытекающими последствиями" обоснуйте эту фразу. Писал VS Code ASP.Net Core проект, и без проблем пользовался, не нашел никаких ограничений. Visual C# это так назывался компонент Express редакции VS. в 2012 VS EXpress поделили не на языки программирования, а на платформо-ориентированные (Web, Desktop, Mobile). Почему вы язык к VS подтягиваете? Компилятор это часть .Net, поставив .Net, MSBuild и Nuget, вы без проблем будете собирать проекты и без VS. Еще раз возможности C# никак, никак вообще не связаны с VS.
Станислав Макаров: ТСу кажется, что конструктор структуры кидает исключение, все в одной строчке, и отладчик на неё встает, а посмотреть кто вызвал исключение ему видать не судьба, как вы и написали скорее всего это cbCOM.SelectedItem
Что то какой до фигни понаписали.
Нету двух спецификаций, она одна, это просто 2 разных организации по стандартизации, те, это если бы вы, к примеру как производитель тушенки, провели бы стандартизацию по ГОСТ и ISO, а тушенка все равно одна и та же.
Второе, Mono особенности не от юридических проблем, ибо стандарт C# открыт, не из за 2 стандартов, как вы думаете. Mono всегда была догоняющей платформой, ибо реализацию .Net никто не раскрывал, фактически Mono результат реверс-инжиринга. Сейчас, когда MS купил Xamarin, все может поменяться.
DarkByte2015: Xamarin - платформа для кроссплатформенной разработки основанная на Mono. Xamarin это фирма (уже купленная MS), которая и придумала Mono. По вашему .Net кроссплатформенный? https://developer.xamarin.com/guides/cross-platfor... читаем "How Does Xamarin Work?", вот цитата:"Xamarin offers two commercial products: Xamarin.iOS and Xamarin.Android. They’re both built on top of Mono, an open-source version of the .NET Framework......." Xamarian Forms это такой же фреймворк для Mono, как и WPF, WinRT, UWP для .Net.
ORTOL: Да дело не в том, что можно и, что нельзя. Я не говорил, что Dephi это плохо. Я как бы могу сравнивать, например Delphi и WPF и UWP, и на мой взгляд, эти платформы гораздо лучше проработаны, да и сама платформа .Net выросла, плюс вся экосистема вокруг .Net гораздо шире. И плюс тенденции вообще все приложения в веб тащить, увы делают Delphi лишь системой для поддержки ранее написанного. Даже возможность создания мобильных приложений не прибавила популярности. Тут только один вопрос, стоимость. Даже сравнить с VS Professional, цена в несколько раз отличатся. Понятно, MS может позволить себе выпускать бесплатные инструменты для разработки, но для Open Source, обучения, исследований VS Community абсолютно бесплатен, а учитывая возможность интеграции с Unity, Cocos2D, становится явным выбор не в пользу Delphi. Можете хоть сколько возражать на этот счет, но Delphi мертв, скорее чем жив, но не потому, что плохой, а потому, что есть гораздо больше альтернатив, и гораздо лучших, и немаловажное бесплатных.
Стас Волянский: Все привязки прописываются в Startup классе в ConfigureServices. Мы добавляем в контейнер и PersonService и PersonRepository. IoC работает рекурсивно. Экземпляры будут по цепочке создаваться, зависимости будут автоматически разрешаться.
вот как должно быть в ConfigureServices
services.AddTransient ()
services.AddTransient
Все, в конструкторе контролера достаточно прописать HomeController(PersonService service), все IoC, создаст сначала PersonRepository, потом создаст PersonService, передав в него экземпляр созданного PersonRepository, а потом и создаст контроллер передав в него PersonService. Вы просто заморочились, на библиотеках, но разрешение зависимостей прописывается в одном месте, в ConfigureServices. Да все в одном месте.
Если вопрос стоит как сделать конфигурацию IoC контейнера именно в библиотеках (ну например, чтобы не тащить все зависимости в основной проект), то тут посложнее. Если вам такое решение нужно, то можно подумать.
Стас Волянский: Еще раз, это не зависимости между слоями. IoC это как раз избавление от прямых зависимостей, вернее от зависимости конкретной реализации. В ConfigureServices вы задаете какую реализацию IoC контейнеру брать для интерфейса. Скажем слой представления у нас зависит от какого интерфеса(сервиса). Мы делаем реализацию этого сервиса, сервис тоже может зависеть, например, от контекста данных или от какого то другого сервиса(который запросы к WebApi реализует). и IoC контейнеру сообщаем какую реализацию брать. Грубо говоря работает все так, стартует приложение, настраивается методами класса Startup, затем отрабатывает маршрутизация, запрашивается конкретны контроллер, IoC контейнер, смотрит на параметры конструктора и создает экземпляры параметров, а уже какой конкретно объект создавать он смотрит по своей внутренне таблице, которую мы и создаем в ConfigureServices. Те, если мы прописали строчку services.AddTransient < IService, PersonService>(); то если в конструкторе класса (а может и метода даже, только там надо пометить параметр атрибутом [FromServices]), будет параметр IService service, то автоматически создастся экземпляр PersonService и передастся в конструктор. IoC контейнер умный очень, опять же создавая экземпляр PersonService, он и на его параметры будет смотреть и также разрешать зависимости, и тд. Опять же повторюсь, AddTransient(а есть и другие еще методы) лишь сопоставляет интерфейс и конкретную реализацию. Это не обязательно слои приложения, это могут быть логеры, анализаторы, что угодно. Итак итог, мы объявляем какой то интерфейс (а можем и не объявлять), делаем реализацию, в ConfigureServices сопоставляем интерфейс и реализацию, а потом просто пишем
public HomeController(IService service). И все и автоматом все создается. если например у Service тоже есть зависимость в конструкторе, она тоже разрешится.
Стас Волянский: в метод ConfigureServices и добавляем библиотеку в зависимости проекта, если же у вас динамически библиотека подгружается, то тут все посложнее.
If you are an enterprise, your employees and contractors may not use the software to develop or test your applications, except for open source and education purposes as permitted above. An “enterprise” is any organization and its affiliates who collectively have either (a) more than 250 computers or users or (b) more than one million US dollars (or the equivalent in other currencies) in annual revenues, and “affiliates” means those entities that control (via majority ownership), are controlled by, or are under common control with an organization.
