Нацелены на .NET4.6 или .NET Core 1 для разработки с нуля?

Я начинаю понимать соглашения об именах для кросс-платформенного стека .NET. В частности, эта страница хорошо объяснила это: http://blog.tonysneed.com/2016/01/22/ef6-asp-net-core-mvc6/

Я начинаю личный проект, который будет полностью с нуля, и рассматриваю его как возможность изучить все эти новые технологии. Однако я хочу повторно использовать код из других приложений MVC5, в которых используются известные библиотеки. Специально для инфраструктуры и сантехники я использовал некоторые известные библиотеки, такие как StructureMap, AutoMapper и EF для сохранения данных (EF 4/5).

Поскольку нет ограничений на то, какую версию я должен использовать, следует ли мне начинать с нуля и использовать последнюю версию ASP.NET Core 1.0, .NET Core 1.0 вместе с EF Core 1.0 или единственным преимуществом использования является только то, что она будет перекрестной. Платформа? Другими словами, если я никогда не собираюсь запускать это ни на чем, кроме Windows, И хочу свести к минимуму проблемы с несовместимостью библиотек, стоит ли мне придерживаться .NET4.6?

Я в основном хочу использовать эту возможность, чтобы иметь возможность изучать новые вещи, не влияя на будущую переносимость моего приложения. Сделает ли MS в конечном итоге .NET Core 1 по умолчанию даже в Windows?


.net .net-core asp.net-core entity-framework-core
person user183872    schedule 01.02.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Не похоже, что MS собирается выбирать между ними, потому что: .NET Core, по сути, является ответвлением NET Framework

На самом деле, когда вы захотите получить его из официального источника, вы все равно столкнетесь с дилеммой.

Ядро Asp.net имеет лицензию Go Live, Microsoft предоставит поддержку и готов к работе, что выбрать?

Отказ от ответственности: остальная часть моего ответа может быть основана на мнении...

Если у вас нет ограничений, например. вам нужны еще неподдерживаемые функции, такие как SignalR, я могу поделиться своим аналогичным опытом:

Я начал с основного веб-API mvc6.

Когда мне понадобился WCF, это было не так просто -> см. здесь< /а>

Затем пришлось использовать целевую библиотеку классов фреймворка 4.5 -> теперь вы можете легко ссылаться на них, и вся обертка вокруг нее будет автоматически делается в Visual Studio

Мне пришлось найти больше способов преодолеть препятствия публикации IIS -> например,

Итог:

большинство проблем решаются в одиночку с новыми частыми выпусками

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

Я могу только добавить, что вы можете быстро прочитать документацию и больше подсказок

person vinjenzo    schedule 01.02.2016
comment
Итак, в целом, есть ли смысл не использовать .NET Core 1.0 с передовой/новой разработкой? - person user183872; 01.02.2016
comment
Заявление об отказе от ответственности все еще включено: я не вижу ни одного, и мне это нравится, но у всех разные бизнес-причины, стоящие за подобными дилеммами. - person vinjenzo; 01.02.2016
comment
docs.microsoft.com/en-us/ dotnet/статьи/стандарт/ - person vinjenzo; 06.04.2017

arrow_upward
2
arrow_downward

Я прошел через эти дебаты и остановился на .NET Core; шесть месяцев спустя и несколько производственных развертываний спустя, я убежден, что это было правильное решение. Вот несколько вопросов, которые могут прояснить ваше решение:

  1. Вы создаете серверную службу, которая соответствует «сладкому пятну» .NET Core, т.е. веб-сайт или веб-/REST API или оба? По моему опыту, .NET Core идеально подходит для этого и уже хорошо работает, хотя EFCore все еще развивается, а инструменты все еще меняются.
  2. Вы хотите создавать службы WCF и другие технологии для Windows? Как правило, вы хотите придерживаться полной платформы .NET, как указано здесь. Приложив немного усилий, можно вызывать службы WCF из веб-API .NET Core.
  3. Очереди сообщений — RabbitMQ теперь имеет поддержку .NET Core, я думаю, что MSMQ у вас может возникнуть проблема — в лучшем случае вам нужно будет ссылаться на полные библиотеки фреймворка.
  4. Если вам требуется какой-либо графический интерфейс на базе Windows — WCF или Winforms — используйте полную инфраструктуру .NET.
  5. Построение фоновых процессов, которые работают как службы Windows — обычно используется полная платформа .NET Framework, не поддерживаемая в .NET Core, хотя вы можете написать ее в .NET Core и создать для нее полную оболочку службы .NET — вероятно, сейчас стоит, если вы также хотите иметь возможность запускать процесс на других платформах.
  6. Если вам нужна возможность запуска кросс-платформы (я так и сделал), вы должны использовать .NET Core.
  7. Если вы хотите использовать Docker для развертывания (как у меня) — .NET Core, похоже, больше внимания уделяет этому, но оба работают, и оба полностью поддерживаются в новых собственных контейнерах Windows 2016.

Надеюсь, это поможет.

person Peter    schedule 10.02.2017