На какую версию .NET Framework и C # мне следует ориентироваться в библиотеке классов? - PullRequest
10 голосов
/ 30 июля 2009

Я создаю библиотеку классов DLL - я хочу, чтобы ее использовали как можно больше людей. Какую версию .NET Framework и какую версию C # мне следует использовать? Можно ли создать обратно совместимую DLL или разные библиотеки DLL для разных версий? Или Windows автоматически обновляет .NET Framework, поэтому я должен просто использовать последнюю версию? Любое руководство приветствуется!

Ответы [ 12 ]

11 голосов
/ 30 июля 2009

Лично я бы нацелился на .NET 2.0. Это означает, среди прочего:

  • Нет методов расширения (хотя есть обходной путь)
  • Нет linq

  • вы МОЖЕТЕ использовать лямбда-выражения

  • вы МОЖЕТЕ использовать ключевое слово 'var'

Дело в том, что вы можете использовать возможности языка C # 3.x (так называемый синтаксический сахар), но вы не можете использовать библиотеки, ориентированные на C # 3.x (System.Core, чтобы назвать одну, включая методы расширения LINQ).

Я бы не стал поддерживать C # 1.x, поскольку он сильно отличается от C # 2.x и выше. Кроме того, я ожидаю, что большинство людей, которые будут использовать вашу библиотеку, это люди, создающие новые вещи, которые в здравом уме не будут использовать C # 1.x; -)

10 голосов
/ 30 июля 2009

Мы ориентируемся на несколько версий времени выполнения (.NET 1.1, .NET 2.0 и .NET 3.5) для некоторых продуктов.

Мы обрабатываем это несколькими способами:

  • Отдельные файлы решений и проектов и для каждого из .NET 1.1, 2.0 и 3.5 SP1, но с указанием одинаковых исходных файлов.

Например:

 \ProductFoo_1_1.sln (.NET 1.1 solution, VS 2003)
 \ProductFoo_2_0.sln (.NET 2.0 solution, VS 2008)
 \ProductFoo_3_5.sln (.NET 3.5 solution, VS 2008)

 \FooLibrary\FooLibrary_1_1.csproj (.NET 1.1 Project, VS 2003) 
 \FooLibrary\FooLibrary_2_0.csproj (.NET 2.0 Project, VS 2008) 
 \FooLibrary\FooLibrary_3_5.csproj (.NET 3.5 Project, VS 2008) 

 \FooLibrary\FooClass.cs (shared amongst all Projects)
 \FooLibrary\FooHelpers_1_1.cs (only referenced by the .NET 1.1 project)

 \FooService\FooService_3.5.csproj (.NET 3.5 Project, VS 2008)
 \FooService\FooService.cs
  • Определение NET_X_X символов в каждом из решений

  • Для специального кода .NET Framework мы используем инструкции препроцессора, такие как:

public void SomeMethod(int param)
{
#ifdef NET_1_1
 // Need to use Helper to Get Foo under .NET 1.1
  Foo foo = Helper.GetFooByParam(param);
#elseif NET_2_0 || NET_3_5
 // .NET 2.0 and above can use preferred  method. 
  var foo =  new Foo { Prop = param }; 
  foo.LoadByParam();  
#endif 
  foo.Bar();
}

#ifdef NET_3_5
// A method that is only available under .NET 3.5 
public int[] GetWithFilter(Func Filter)
{ 
  // some code here
}
#endif 

Для пояснения вышеупомянутые строки, начинающиеся с #, являются командами препроцессора. Когда вы компилируете решение, C # Compiler (csc) предварительно обрабатывает исходные файлы. Если у вас есть оператор #ifdef, то csc оценит, чтобы определить, определен ли этот символ - и, если да, включите строки в этот сегмент при компиляции проекта.

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

#if DEBUG_VERBOSE
  Logging.Log("Web service Called with parameters: param = " + param);
  Logging.Log("Web service Response: " + response); 
  Logging.Log("Current Cache Size (bytes): " + cache.TotalBytes); 
  // etc. 
#endif 
  • Затем у нас есть сценарии NAnt, которые автоматизируют создание релиза для каждой версии .NET. Мы можем контролировать все это через TeamCity, но мы также можем запускать сценарии NAnt вручную.

Это усложняет ситуацию, поэтому мы склонны делать это только там, где нам нужно поддерживать устаревший экземпляр .NET 1.1 или 2.0 (например, когда клиент не может / не хочет обновляться).

Я предполагаю, что когда развернется .NET 4.0, мы сделаем то же самое и просто добавим символ NET_4_0.

9 голосов
/ 30 июля 2009

Я бы оставил его на уровне 2.0, если вам не нужно использовать функции 3.0 или 3.5.

4 голосов
/ 30 июля 2009

попробуйте это:

переключение режима нацеливания на framework 2.0 (без ссылки на System.Core).

если не скомпилировать, то попробуйте добавить ссылку на linqbridge.dll :

Если нет, то вы должны нацелиться на 3,5;)

2 голосов
/ 30 июля 2009

Если бы я начал новый проект, я бы всегда использовал новейшую среду выполнения! Если доступна версия 3.5, зачем мне начинать проект с 2.0 или 1.0, если я не знаю, что с новой версией что-то серьезно? Новые версии означают исправление старых ошибок и добавление новых функций, так что это хорошо.

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

Будьте внимательны, потому что новые инструменты могут не поддерживать старые версии. Хотя это не относится к 2010 году, поскольку он будет поддерживать все версии до 2.0.

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

Это решение работает довольно хорошо. Я просто настроил два разных проекта, каждый из которых имеет уникальные «Свойства проекта-> Сборка-> Условные символы компиляции» и использовал в коде так:

#if NET_4
            xmlReaderSettings.DtdProcessing = DtdProcessing.Ignore; 
#endif
#if NET_3_5
            xmlReaderSettings.ProhibitDtd = false;                
#endif
0 голосов
/ 03 июня 2011

В сочетании с использованием подхода, подобного упомянутому Уиллом Хьюзом, если вы хотите, чтобы доступ / опция использовали более новые функции, когда они доступны, во время активной разработки используйте новейшую платформу. Когда будете готовы приступить к созданию кандидатов на выпуск, установите самую низкую платформу, а затем, когда возникнут проблемы, постоянно повышайте версию платформы и / или используйте подход #ifdef для разработки.

0 голосов
/ 30 июля 2009

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

0 голосов
/ 30 июля 2009

Это зависит от того, для чего dll. Если он просто имеет общую логику C #, которую вы хотели бы сделать доступной для других, то .net 2.0, вероятно, будет вашим лучшим выбором. Однако если он имеет какое-либо отношение к более новым функциям в .net, таким как WPF, EF, WCF, silverlight, ect, то он должен быть в версии .net, поддерживающей эту конкретную функцию.

Лично я бы сказал, что пишите его в .net 3.5 только потому, что переход с .net2.0 на .net3.5 довольно безболезненный, поскольку в отличие от перехода с .net1.x на .net2 изменений не так много +0,0. :)

0 голосов
/ 30 июля 2009

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

...