Фреймворк нет: Как установить .NET Framework на Windows Server — Serverspace

В чем разница между .NET Framework и .NET Core?

Microsoft предоставляет две разные среды выполнения .NET: .NET Framework и .NET Core. Оба реализуют .NET Standard, и код между ними достаточно кросс-совместим, но .NET Framework работает только в Windows. Мы обсудим различия между двумя средами выполнения.

Краткий ответ: кроссплатформенная совместимость

Быстрый ответ: .NET Core работает в Linux и macOS, а .NET Framework работает только в Windows. Вы бы использовали .NET Core, когда вам нужна кросс-платформенная совместимость, и вы бы использовали .NET Framework, когда вам нужны специальные службы Windows и пакеты NuGet, которые не были перенесены в .NET Core.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

.NET Core является преемником .NET Framework, так что это определенно то, что вы хотите выбрать в будущем. Он оставляет после себя некоторые функции только для Windows, но многие из них все еще могут поддерживаться Пакет обеспечения совместимости с Windows расширение.

В целом Core и Framework почти одинаковы, но на практике у них есть небольшие различия. И .NET Core, и .NET Framework используют один и тот же API, называемый .NET Standard, но Core имеет открытый исходный код, а Framework — это реализация Microsoft только для Windows.

В общем, Core немного легче, чем Framework, так как он разработан и часто используется с Docker в серверных модулях на основе микросервисов. Помимо возможности использовать Linux в первую очередь (что необходимо для Docker), получившийся образ будет немного меньше с .NET Core.

Помимо этого, большая часть различий заключается в различиях пакетов NuGet. Например, Entity Framework Core немного отличается от Entity Framework 6, который работает на .NET Framework. ASP.NET Core сильно отличается от ASP.NET 4, поскольку они многое переработали для .NET Core.

Когда использовать .NET Core

Вы должны использовать .NET Core поверх .NET Framework в следующих случаях:

• Вы необходимость кроссплатформенная совместимость. Сюда входит использование архитектур Docker и микросервисов.
• Вы начинаете новый проект, и вам просто нужно выбрать один. (.NET Core новее.)
• Вы не используете специальные инструменты, библиотеки или пакеты NuGet для Windows, которые зависят от .NET Framework.
• Вы хотите максимально возможную производительность. Microsoft рекомендует .NET Core с ASP.NET вместо .NET Framework.
• Вы хотите запускать несколько версий .NET Core одновременно друг с другом. Framework не поддерживает это.
• Вы хотите получить доступ к интерфейсу командной строки в Linux или запустить сервер сборки CI / CD в Linux.

Когда использовать .NET Framework

Вы должны использовать .NET Framework поверх .NET Core в следующих случаях:

• Вы ориентируетесь только на развертывание Windows.
• Вы интенсивно используете пакеты и библиотеки Windows, такие как Windows Forms, WPF, ASP.NET Web Forms / Pages и Windows Workflow Foundation.
• Используемые вами технологии не добавляются Пакет обеспечения совместимости Windows для . NET Core.
• Вы уже используете его, и миграция потребует слишком много усилий.

Как перейти на .NET Core

Обычно это будет «как переключиться с Framework на Core», потому что любой существующий работающий проект на .NET Core, скорее всего, не нуждается в переключении обратно на старую .NET Framework.

Если вы используете что-то специфичное для Windows, вы не сможете. Вы застряли на .NET Framework до тех пор, пока используемые вами компоненты не получат версии Core, а некоторые вещи не будут происходить, как с ASP.NET WebForms.

Самым простым решением было бы создать новое Решение и проект на основе .NET Core и перенести туда свой код. Если у вас есть простое приложение, это, вероятно, самое простое решение.

В противном случае вы можете использовать dotnet try-convert, или следовать Руководство Microsoft по портированию.

Для больших сложных проектов вы можете использовать Анализатор переносимости .NET. Это инструмент от Microsoft, который просканирует ваш проект, расскажет, насколько сложным может быть преобразование, и покажет, какими должны быть ваши следующие шаги.

Он также может создать ориентированный график ваших зависимостей, который поможет вам увидеть, что еще требует анализа. Некоторые проекты будет сложнее перенести, чем другие, и если вы используете что-то, недоступное в Core, возможно, вы вообще не сможете перенести без обходного пути.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Метки записи: #NET

Похожие записи

c# — Объясните на пальцах совместимость библиотек в .Net Core, .Net Framework, .Net Standart

Изучаю .Net. Хочу написать некое серверное приложение (думаю что учеба лучше на реальном примере, нежели писать примитивные hello world). Выбор уходит в сторону .Net Core (микросервис). В проекте нужно будет использовать некоторые библиотеки (далее пример приведу). Из всего прочитанного понял следующее (если что не правильно понял поправьте):

1. Net Standart — вершина «айсберга» (своего рода типа интерфейс для остальных проектов)
2. Net Core, Net Framework, Xamarin — ниже по иерархии (типа как классы реализующие интерфейс), но могут (и скорее всего так и делают) добавлять свои специфические фичи, характерные для каждого из них.
3. Библиотеки (dll-ки) написанные как классы Net Standart могут использоваться в любом из наследников (Net Core, Net Framework, Xamarin) с полной совместимостью (а если быть точным то смотреть таблицу реализации https://docs.microsoft.com/en-us/dot…tation-support), но не наоборот (т.е. к примеру если библиотека написана как Net Framework dll (со специфическими для Net Framework фичами), то не факт что ее можно использовать в Net Core, потому как он не поддерживает специфические фичи из Net Framework)
4. Каждая последующая версия Net Standart, Net Core, Net Framework, Xamarin включает в себя все фичи из предыдущей версии самой себя + некоторые новые. Т.е. к примеру код написанный под Net Standart 1.3 будет 100% работать в Net Standart 2.0, НО код написанный под Net Standart 2.0 не будет работать в Net Standart 1.3 и выше.

И теперь собственно на реальном примере. Буду использовать .Net Core 2.0 и смотреть совместимость естественно с Net Standart 2.0 и .NETFramework 4. 6.1. Выбираю два пакета (библиотеки) на сайте nuget. Первый к примеру Selenium Webdriver https://www.nuget.org/packages/Selenium.WebDriver/ Во вкладке dependencies смотрю что ему надо (я понимаю что все это подтянется автоматом в visual studio, вручную не надо):

.NETFramework 3.5
No dependencies.
.NETFramework 4.0
No dependencies.
.NETFramework 4.5
No dependencies.
.NETStandard 2.0
Newtonsoft.Json (>= 10.0.3)

Как я понимаю ему не нужны никакие зависимости из .NETFramework, но нужна одна зависимость из .NETStandard 2.0. Но для Newtonsoft.Json (>= 10.0.3) тоже нужны зависимости https://www.nuget.org/packages/Newtonsoft.Json/

.NETFramework 2.0
No dependencies.
.NETFramework 3.5
No dependencies.
.NETFramework 4.0
No dependencies.
.NETFramework 4.5
No dependencies.
.NETStandard 1.0
Microsoft.CSharp (>= 4.3.0)
NETStandard.Library (>= 1.6.1)
System.ComponentModel.TypeConverter (>= 4.3.0)
System.Runtime.Serialization.Primitives (>= 4.3.0)
.NETStandard 1. 3
Microsoft.CSharp (>= 4.3.0)
NETStandard.Library (>= 1.6.1)
System.ComponentModel.TypeConverter (>= 4.3.0)
System.Runtime.Serialization.Formatters (>= 4.3.0)
System.Runtime.Serialization.Primitives (>= 4.3.0)
System.Xml.XmlDocument (>= 4.3.0)
.NETStandard 2.0
No dependencies.

Вот тут я немного в ступоре. Если я буду использовать .Net Core 2.0, а он в свою очередь реализует .NETStandard 2.0, то как я понимаю для Newtonsoft.Json уже не нужны зависимости из .NETStandard 1.0 и .NETStandard 1.3, потому как все это уже есть в .NETStandard 2.0.

Т.е. будет ли пакет Selenium.WebDriver совместим с .Net Core в данном случае?

И еще один пример, есть пакет cefSharp: https://www.nuget.org/packages/CefSharp.OffScreen/65.0.0-pre01 Он тянет зависимость CefSharp.Common (= 65.0.0-pre01) Та еще две, но эти последние две не тянут ничего https://www.nuget.org/packages/cef.redist.x64/

This package has no dependencies.

В этом случае ни слова про .NETStandard и . NETFramework. Т.е. как я понимаю они вообще самодостаточные? Т.е. как они будут работать в .Net Core?

Длинный вопрос получился, но надеюсь вы поняли, в чем я хочу разобраться: Как выяснить совместимость пакета с определенной реализацией .NET?

Лучший фреймворк Go: нет фреймворка?

Во время написания этого блога и руководства командами Go в течение нескольких лет, самый частый вопрос, который я слышал от новичков, был

«Какой фреймворк мне использовать?». Одна из худших вещей, которые вы можете сделать в Go, — это следовать подходу других языков программирования.

Для других языков установлены рамки «по умолчанию». В Java есть Spring, в Python — Django и Flask, В Ruby есть Rails, в C# — ASP.NET, в Node — Express, а в PHP — Symfony и Laravel. Иди по-другому: там нет фреймворка по умолчанию .

Что еще более интересно, многие предлагают вообще не использовать фреймворк. Они сумасшедшие?

Сборка сервиса Go из библиотек может дать ощущение создания монстра Франкенштейна

Философия Go языки.

Это не скоро изменится.

Вы можете подумать, что это потому, что экосистема Go моложе. Но есть более важный фактор. Go построен на философии Unix, которая гласит:

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

Эта философия возникла у Кена Томпсона, разработчика языка программирования B (предшественника C), а также… Идти!

На практике

философия Unix предпочитает создавать небольшие независимые части программного обеспечения, которые хорошо выполняют одну задачу, а не большие куски, которые делают все. Возможно, вы видели это в своем терминале. Например: cat example.txt | сортировать | уникальный . cat читает текст из файла, sort сортирует строки, а uniq удаляет дубликаты. Все команды независимы и делают одно дело. Это происходит непосредственно из философии Unix. Благодаря такому дизайну вы можете самостоятельно разрабатывать гораздо более мелкие автономные команды.

В Go философия Unix видна в стандартной библиотеке. Лучшими примерами являются самые распространенные интерфейсы: io.Reader и io.Writer . Лучшие библиотеки также следуют этой философии.

Фреймворки разработаны с учетом этой философии. Часто они пытаются охватить все возможные варианты использования в рамках одного фреймворка. Они не предназначены для работы с другими инструментами и часто не могут использоваться повторно. Это означает, что невозможно перенести усилия по разработке на другие несовместимые фреймворки. Если внедрение фреймворка низкое (или оно просто умирает), все усилия потеряны.

Вы опытный инженер, который хочет изучить основы Go?

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

Что для вас важно

У каждого технического решения есть компромиссы. Вам нужно выбрать компромиссы, которые имеют больше смысла для вас и вашего проекта.

Некоторые подходы имеют смысл, когда вы работаете над проверкой концепции за один уик-энд и отбрасываете ее (вы это сделаете, верно?). В этом случае наиболее важным фактором является то, насколько быстро вы сможете это сделать. Но если вы работаете над проектом, который будет длиться долго, и вы строите его с участием нескольких человек, влияние этого решения огромно.

Для большинства проектов наиболее важными параметрами являются:

• насколько быстро вы можете запустить проект,
• насколько быстро вы сможете развивать этот проект в долгосрочной перспективе,
• насколько гибким для будущих изменений будет проект (это сильно связано с предыдущим пунктом).

Давайте начнем оценивать наши решения.

Экономия времени

Одним из самых больших обещаний фреймворков является экономия времени. Вы запускаете одну команду и получаете полнофункциональный проект. Фреймворки обычно обеспечивают самоуверенную структуру проекта, и это помогает, если вы не знаете, как это сделать. Но, как и в случае с большинством других технических решений, это не бесплатно.

Со временем, когда проект разрастется, вы быстро столкнетесь со стеной условностей и ограничений фреймворка. Требования к автору фреймворка, вероятно, отличались от ваших. Решение, принятое создателем фреймворка, может хорошо работать для простых CRUD-приложений, но может не справляться с более сложными сценариями. Легко быстро потерять все время, сэкономленное на начальной загрузке проекта, только на борьбу с одним ограничением фреймворка. Со временем это может привести к большому разочарованию в вашей команде.

Пару лет назад я работал в компании, которая изначально начинала с одного фреймворка Go (название фреймворка опущу). Компания росла и создавала новые услуги. Со временем мы начали чувствовать больше боли, когда хотели поддерживать более сложные варианты использования. Это также было источником серьезных ошибок. К сожалению, избавиться от фреймворка было непросто.

В какой-то момент некоторые компоненты фреймворка перестали поддерживаться и стали несовместимы с остальной частью экосистемы. Мы были вынуждены избавиться от него. Фреймворк уже стал очень тесно связан со всей системой. Убрать его из десятков сервисов оказалось нетривиальной задачей. Потребовалась межкомандная инициатива, на устранение которой ушло несколько человеко-месяцев и несколько инцидентов. Даже если в итоге проект и удался, я не видел его таким. Все затраченное время можно было бы использовать гораздо лучше, если бы кто-то принял другое решение раньше. Весь проект был бы не нужен. Неудивительно, что многие компании страдают от недоверия к команде разработчиков.

Это отличный пример того, как такое маленькое решение может стать дорогостоящим спасательным проектом после нескольких годы.

Ремонтопригодность проекта

Измерение ремонтопригодности проектов — спорная тема — сложно сравнивать два проекта. Некоторые люди говорят, что фреймворки — это здорово, и они не испытывают боли при их использовании. Для других фреймворки могут стать самым большим кошмаром в долгосрочной перспективе. Некоторые проекты намного сложнее, чем другие. Многие думают, что борьба с фреймворком — это только часть работы. Вот почему трудно объективно измерить влияние фреймворков на ремонтопригодность проекта.

К счастью, мы можем помочь себе понять это, применив немного науки. Точнее, с отличной книгой Accelerate: The Science of Lean Software and DevOps , основанной на научное исследование. Книга ориентирована на поиск характеристик лучших и худшие команды. Что важно для нас, один из наиболее значимых факторов для хорошей работы слабосвязанная архитектура.

Группы, которыми я руководил, часто спрашивали меня, как узнать, является ли наша архитектура слабосвязанной. Один из самых простых способов — обеспечить простоту замены или удаления частей вашего приложения. Если трудно удалить части вашего приложения, ваше приложение тесно связано. Прикосновение к одной вещи вызывает эффект домино изменений в разных местах.

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

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

Альтернатива? Создание сервисов без фреймворка

Вам может показаться, что создание сервисов без фреймворка займет целую вечность. Особенно, если вы пришли из других языков программирования. Я это понимаю. У меня было такое же чувство пару лет назад, когда я начал писать на Go. Это был необоснованный страх. Отсутствие фреймворка не означает, что вам нужно будет создавать все самостоятельно. Существует множество проверенных библиотек, предоставляющих необходимую вам функциональность.

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

Что делать, если вы решили не использовать фреймворк? Самым большим препятствием в начале может быть то, как вы создаете сервис. Проще всего начать с того, что поместить все в один файл. Вы можете начать с простого, отложить некоторые решения и со временем развивать свой проект.

Полезно иметь примеры проектов, которые можно использовать в качестве справочных материалов. Вы можете взглянуть на проект, который я использовал для своей презентации «Давайте создадим управляемое событиями приложение за 15 минут» с презентацией Watermill на GoRemoteFest — github.com/roblaszczak/goremotefest-livecoding. В этом примере для работы потребовалось всего две внешние библиотеки.

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

Удобно изменять части вашего проекта, не убивая его.

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

Если вы ищете справку о том, как могут выглядеть более сложные проекты, вам следует проверить Wild Workouts — наш полнофункциональный пример Go-проекта. Мы выпустили бесплатную электронную книгу +200 страниц, описывающую, как мы создали это приложение.

Резюме

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

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

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

У вас есть страшилки с фреймворком (даже из другого языка программирования)? Дайте нам знать об этом в комментариях!

Бескаркасное движение

Звезда репо!

Движение Frameworkless Movement — это группа разработчиков, заинтересованных в разработке приложений без фреймворков. Мы не ненавидим фреймворки , и мы никогда не будем проводить кампании против фреймворков, но мы воспринимаем неправильное использование фреймворков как отсутствие знаний о техническом долге и наличии альтернатив, предоставляемых ванильным языком или специальными библиотеками.

Каждый раз, когда команда использует фреймворк, она также подвергается риску . Риск заключается в том, что по прошествии некоторого времени команда окажется с инструментом, который больше не представляет никакой ценности и который в большинстве случаев представляет собой серьезное препятствие для внесения изменений. Самое главное, что фреймворк может «умереть» задолго до того, как программное обеспечение начнет его использовать, оставив разработчиков тяжелым бременем.

Этот риск усиливается без наличия прочной связи между принятием технических решений, бизнес-целями и пользовательским опытом. Вместо этого нефункциональные требования, такие как крайний срок, продолжительность жизни, бюджет, удобство использования, будущие бизнес-сценарии и ограничения, связанные с предметной областью, должны быть основными факторами принятия решений для выбора архитектуры, а также для дорожной карты реализации.

Что такое бескаркасное движение

Как мы уже говорили выше, мы не считаем фреймворки злом . Это очень мощные инструменты, написанные простым ванильным языком и в очень общем виде, что делает их отличными инструментами для обучения, которые могут помочь любому научиться кодировать без них . Чтобы знать, как и когда вы должны использовать конкретный фреймворк, вы должны понимать, как работают фреймворки. Понимание сильных сторон и ограничений каждого фреймворка позволит вам сделать правильный выбор фреймворка. Более того, будет очень ясно, когда он вам вообще не нужен. Понимание концепций того, как фреймворки работают за кулисами, углубит ваши знания о самом языке. Знание основ фреймворка позволит вам писать лучший код для каждой конкретной проблемы, с которой вы сталкиваетесь.

Тем не менее, мы считаем, что выбранный фреймворк следует ответственно использовать на протяжении всего жизненного цикла проекта. Постоянно напоминайте себе, что у каждого инструмента есть компромисс.

Отсутствие фреймворка означает, что вы должны придавать правильное значение процессу принятия технологических решений и осознавать, что выбор в пользу разработки проекта или отдельной функции без зависимости от фреймворка вполне возможен!

Отсутствие фреймворка также означает, что вы должны учитывать весь контекст, в котором программное обеспечение должно будет «родиться» и «жить». Включая навыки разработчиков, которые должны разрабатывать программное обеспечение, решая, могут ли они получить помощь от фреймворка, учитывая причины, поддерживающие этот выбор, и его компромиссы.

Наконец, отсутствие фреймворка означает, что вы не должны полагать, что написание программного обеспечения — это обязанность, которую вы можете позволить себе делегировать кому-то еще и полагаться на другое программное обеспечение (например, библиотеку) для решения вашей конкретной проблемы. Вы можете избежать привязки рук и ног к целому каркасу, когда он вам действительно не нужен.

Наш манифест

Наш манифест опубликован в нашем репозитории GitHub. Мы твердо верим , что для того , чтобы этот манифест был полезным , он должен быть изменен в течение времени в результате обсуждений , которые будут вести наше сообщество . Таким образом, невозможно будет подписать этот Манифест. Если вы найдете этот Манифест полезным для своей работы, поделитесь им со своей сетью. Совместное использование — это то, как мы хотели бы, чтобы люди подписали этот документ.

Является ли Frameworkless только для разработчиков?

Поскольку исследования пользователей, действия по проектированию и бизнес-цели больше проясняют нефункциональные требования, мы считаем важным привлечь к обсуждению всех, кто работает над проектом, включая не-разработчиков. Каждое техническое решение, включая выбор фреймворка, должно приниматься с учетом всех аспектов контекста, в котором «живет» программное обеспечение.

Ресурсы

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

Примите участие

Мы принимаем любые отзывы , поэтому, если вы хотите обсудить с нами какую-либо из тем, изложенных здесь, просто откройте вопрос или запрос на слияние.