Как развить кодовую базу .NET над версиями .NET

Question

У меня есть набор компонентов .NET, которые были разработаны давно (1.1). Я хотел бы продолжить предоставлять их для версии 1.1 для любых клиентов, которым нужна эта версия, но также предлагать версии - в некоторых случаях один и тот же код, в некоторых случаях с улучшениями - для .NET 2 и .NET 3 (.5). В каждом последующем случае я мог бы использовать преимущества новых функций платформы для определенных компонентов.

Я ищу руководство относительно того, как лучше всего поступать в этой ситуации.

В случае, когда я не собираюсь вносить какие-либо изменения в компонент, тогда я думаю, что я все еще мог бы предоставить его как 1.1, так и более поздние библиотеки / приложения могли бы просто потреблять сборки 1.1 как есть. Я подозреваю, что все еще могут быть веские причины для предоставления сборок, созданных с более поздними версиями .NET - например, производительность - но я понимаю, что я мог бы просто поставить 1.1. Это правильно?

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

• Отдельные ветви кода
• C # препроцессор
• Предоставьте функциональность в отдельных (новых) классах для версий .NET 2+ и используйте оригинал, скажем, через композицию
• какой-то другой продвинутый трюк .NET, о котором я пока не знаю

Кроме того, любые советы по поводу того, что делать с подписью сборки, будут с благодарностью.

Заранее спасибо

Answer 1

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

Фактически, кроме поддержки оборудования, я не думаю, что слышал о каких-либо веских причинах, по которым машина не будет обновлена ​​до .NET 3.5 SP1. Что касается приложений .NET 2.0, то .NET 3.5 SP1 - это просто .NET 2.0 SP2. Вы должны задаться вопросом, почему кто-то не хочет внедрять пакет обновления, который существует уже почти год.

Все остальные .NET 3.0 и .NET 3.5 - это просто дополнительные сборки, которые не могут повлиять на код, который их не использует.

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

Еще одна странная мысль: неужели мы не даем возможность компаниям .NET 1.1 продолжать поддерживать их, как если бы на это не было никаких дополнительных затрат? Действительно ли мы делаем им какую-то услугу, помогая им держать голову в песке? Даже если они слишком заняты, чтобы увидеть это, это не займет много времени, прежде чем какой-то стартап начнет конкурировать с ними и выиграть большую часть своего бизнеса, не потому, что они лучшая компания, а потому, что они используют WCF и ASP.NET MVC и AJAX и все классные функции, о которых люди .NET 1.1 могут только мечтать.

Answer 2

Я поддерживаю проект для .NET 2.0, .NET 3.0, .NET 3.5 CF 2.0, CF 3.5, Mono 2.x и Silverlight 2.0 - я делаю большую часть этого, используя комбинацию файлов проекта (сборки) и #if директивы, чтобы минимизировать / локализовать количество дублирующегося кода.

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

Важной задачей является убедиться, что вы настроили это так, чтобы вы могли быстро собрать / протестировать их все - например, у меня есть один «build.bat», который будет проверять, что он компилируется во всех них (это действительно легко ввести недопустимый синтаксис).

Для 1.1, я полагаю, вы могли бы использовать MSBee, но вам может понадобиться "csc" - но есть некоторые довольно фундаментальные изменения (например, не генерики), поэтому это может быть на порядок сложнее ...

Answer 3

Здесь ваши файлы сборки очень важны. Вместо использования препроцессора я бы использовал MSBuild (посмотрите MSBee для компиляции кода .NET 1.1 с использованием MSBuild), чтобы создать файл сборки, в котором будет указано, как создавать каждую платформу сборка.

Answer 4

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

Я думаю, что это в основном будет зависеть от того, как вы ожидаете, что кодовая база будет расти в будущем. Если вы ожидаете ограниченных изменений в замененных версиях, я просто продолжу и перейду к большей части новой функциональности, входящей в новейшее поколение .NET, чтобы использовать новые языковые функции. Большинство ваших новых функций появилось в версиях 3.0 и 3.5, поэтому я предпочел бы попытаться привлечь клиентов, если это возможно; они получают новый язык, и вы сосредотачиваете свое внимание на построении преимущественно одной структуры.