Какую версию .NET выбрать? - PullRequest
       56

Какую версию .NET выбрать?

8 голосов
/ 13 января 2012

Я пишу общедоступную версию библиотеки классов .NET для нашей онлайн-службы REST и не могу решить, какую версию .NET выбрать.

Я хотел бы использовать версию .NET 4.0, но такой скомпилированный классбиблиотека не может быть использована в версии .NET 2.0?

Может, есть статистика, сколько разработчиков используют версию .Net 2.0?

Ответы [ 8 ]

10 голосов
/ 13 января 2012

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

Единственное преимущество нацеливания на более ранние версии фреймворка - тщетная надежда на то, что пользователю не придется ничего скачивать и устанавливать, чтобы использовать ваше приложение. Но это далеко не надежно, и в основном напрасно. Помните, что Windows не является каналом доставки .NET Framework , и вы не можете с уверенностью предположить, что у пользователя будет установлена ​​ любая версия .NET Framework. Даже если вы настаивали на том, что он входит в комплект поставки Windows (чего не следует делать), многие пользователи все еще не обновились с Windows XP. Даже если вы рассчитывали на то, что он будет вытеснен через Центр обновления Windows, существует значительное число пользователей, которые либо не используют Центр обновления Windows, либо не часто используют Центр обновления Windows, либо живут в удаленных районах с плохим / медленным доступом в Интернет. и не могу загрузить все эти обновления.

Мораль этой истории в том, что вам все равно придется предоставить подходящую версию .NET Framework вместе с вашим приложением. И среда выполнения .NET 4.0 на самом деле значительно меньше , чем предыдущие версии, поэтому нет особых причин для их нацеливания. Команда очень усердно работала над этим , и их усилия действительно окупились. Более того, как отмечает Atornblad, большинство приложений могут ориентироваться на версию платформы Client Profile, которая обрезает некоторые редко используемые элементы и сокращает их еще на ~ 16%.

Кроме того, я настоятельно рекомендую использовать приложение установки, которое автоматически и без проблем обрабатывает установку необходимой платформы для пользователя. Visual Studio поставляется со встроенной поддержкой для создания приложений установки, или вы можете использовать стороннюю утилиту установки, такую ​​как Inno Setup . Это делает использование последней версии легкой задачей.

5 голосов
/ 13 января 2012

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

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

Конечно, если вы знаете всех своих клиентов и знаете, что они все смогут использовать .NET 4, тогда пойдем с этим.

Большие недостатки использования .NET 2.0 заключаются в том, что вы не сможете использоватьLINQ внутри (если вы не используете LINQBridge или что-то подобное, что добавляет другую зависимость для вашей библиотеки), и вы не сможете (чисто) предоставить методы расширения.Если вы можете с пользой предоставить больше возможностей клиенту, если вы используете более позднюю версию, вы можете захотеть предоставить несколько версий библиотеки - но, очевидно, это головная боль при обслуживании.

Еще одно соображениедолжны ли вы предоставлять версию Silverlight - что опять-таки зависит от того, какую услугу вы предоставляете и каких пользователей вы ожидаете.

2 голосов
/ 13 января 2012

Если вы предоставляете услугу REST, вам, вероятно, следует использовать 4.0.

Единственный раз, когда вам нужно рассмотреть возможность использования устаревшей версии, это если другой проект должен ссылаться на вашу скомпилированную dll. Служба REST предоставляется с использованием HTTP через Интернет, и клиент не будет использовать .dll напрямую. Или я неправильно понял вопрос?

1 голос
/ 13 января 2012

Я бы пошел на компромисс и использовал бы самый старый фреймворк, который обеспечивает вам (автору библиотеки) максимальную отдачу от ваших денег.Это компромисс, который позволяет вам разрабатывать быстрее и предоставляет вашу библиотеку большему количеству пользователей.Для меня это обычно означает 3,5, потому что я склонен широко использовать LINQ.

1 голос
/ 13 января 2012

Если я вас не правильно понял, вы ищете создание клиентской библиотеки на основе .NET для работы с некоторыми REST-сервисами, сделанными вами тоже.

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

Возможно, есть еще подходы, но я бы хотел предложить вам три из них:

  1. Условный подход на основе компиляции . Вы можете реализовать свои классы, используя общий набор функций, найденный в устаревших и более новых версиях фреймворка, но используя преимущества полезных функций, присутствующих в каждой версии. Это возможно с использованием условных символов компиляции и компиляции, поскольку вы можете определить конкретный код для компиляции в зависимости от целевой версии платформы (проверьте этот вопрос: Можно ли условно скомпилировать в версию .NET Framework? ).

  2. Символические ссылки в подходе на основе Visual Studio 2010 . Вы можете использовать общий набор функций, имея в виду, что он будет найден в самой старой версии. То есть вы можете создать проект, который компилируется в 2.0 и другие для более новых версий, добавляя все скомпилированные файлы и встроенные ресурсы в виде символических ссылок в этих проектах Visual Studio. Это создаст сборку для любой из поддерживаемых версий фреймворка. Вы можете смешать подход на основе условной компиляции с этим, и вы можете получить отличный способ доставки вашей публичной сборки в различных версиях фреймворка очень надежным и простым в обслуживании способом. Обратите внимание: всякий раз, когда вы добавляете новый скомпилированный файл или ресурс в проект, вам необходимо создать для него соответствующие символические ссылки для других ваших проектов . Прочтите эту статью MSDN, если вы хотите узнать больше о связанных файлах: http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx.

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


Мое мнение

По-моему, я бы выбрал подход № 2, потому что он имеет лучшее из № 1 и № 3. Если вы привыкнете к нему, его легко поддерживать, и все дело в дисциплине, и у вас будет хороший выбор для ваших клиентов-разработчиков.

1 голос
/ 13 января 2012

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

1 голос
/ 13 января 2012

Это почти всегда - хорошая идея использовать последнюю версию, потому что MS предлагает множество исправлений и нововведений в них.

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

Для версий приблизительного распределения, можете посмотреть этот ТАК ответ (но это до версии 3.5)

0 голосов
/ 13 января 2012

Обеспечивать двоичные файлы версии 2.0 и 4.0 тривиально, если вы не используете какие-либо специфичные для 4.0 библиотеки DLL.

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

...