Лучшие практики для именования блока и управления версиями?

Question

Лучшие практики для именования блока и управления версиями?

Это ограничение повлияло на меня, когда я пытался перегрузить операторы для общих типов; так как не было ограничений «INumeric», и для множества других причин хорошие люди в stackoverflow с удовольствием предоставляют, операции не могут быть определены на общих типах.

Мне хотелось что-то вроде

public struct Foo<T>
{
    public T Value{ get; private set; }

    public static Foo<T> operator +(Foo<T> LHS, Foo<T> RHS)
    {
        return new Foo<T> { Value = LHS.Value + RHS.Value; };
    }
}

Я работал над этой проблемой с использованием динамического ввода времени .net4.

public struct Foo<T>
{
    public T Value { get; private set; }

    public static Foo<T> operator +(Foo<T> LHS, Foo<T> RHS)
    {
        return new Foo<T> { Value = LHS.Value + (dynamic)RHS.Value };
    }
}

Две вещи об использовании dynamic:

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

38

c# .net assemblies versioning

задан starblue 25 April 2009 в 12:33

4 ответа

Один способ определить Ваше управление версиями состоит в том, чтобы дать семантическое значение каждой части:

Идут от N.x до N+1.0, когда совместимость порывает с новым, повторно генерируют
, Идут от Нью-Мексико до N.M+1, когда новые опции добавляются, которые не повреждаются, совместимость
Идут от N.M.X до N.M.X+1, когда исправления ошибок добавляются

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

, О, и не забывают публиковать правила, Вы придумываете так людей, знают, что ожидать.

21

ответ дан andy 12 November 2019 в 04:50

Семантическое управление версиями имеет ряд рекомендаций и правил относительно того, как применять это (и когда). Очень просто следовать, и это просто работает.

http://semver.org/

8

ответ дан Bil Simser 12 November 2019 в 04:50

Первая вещь, которую я рекомендовал бы, состоит в том, чтобы познакомиться с различиями между версией блока и Версией файла. К сожалению.NET имеет тенденцию рассматривать их как то же когда дело доходит до файлов AssemblyInfo в этом, это обычно только помещает AssemblyVersion и позволяет FileVersion принимать значение по умолчанию к тому же значению.

, Так как Вы сказали, это - совместно используемая сборка, я предполагаю, что Вы подразумеваете, что она совместно используется на двоичном уровне (не включением проекта в различных решениях). Если это так, Вы хотите быть очень преднамеренными об изменении версии блока как, какая.NET использует для строгого имени блок (чтобы позволить Вам помещать его в GAC) и также составляет "полное имя блока". Когда изменения версии блока, это может иметь повреждающиеся изменения для приложений, которые используют его, не добавляя записи перенаправления блока в app.config файле.

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

CompanyName.Framework.Core

, если это - часть более крупной библиотеки, или просто

CompanyName.Shared
CompanyName.Core
CompanyName.Framework

До, когда увеличить номера версий, это все еще довольно субъективно и зависит от того, что Вы полагаете, что каждая часть номера сборки представляет. Схема Microsoft по умолчанию является Главной. Незначительный. Сборка. Пересмотр, но это не означает, что Вы не можете придумать свои собственные определения. Самая важная вещь состоит в том, чтобы быть последовательной в Вашей стратегии и удостовериться, что определения и правила имеют смысл через все Ваши продукты.

почти В каждой схеме версии я видел, что первые две части являются Главными. Незначительный. Номер основной версии обычно увеличивает, когда существуют большие изменения и/или повреждающиеся изменения, в то время как номер вспомогательной версии обычно увеличивает, чтобы указать, что что-то изменилось, который сделал не было повреждающееся изменение. Другие два числа значительно более субъективны и могут быть "сборкой" (который часто является временами последовательное значение даты или последовательно обновляющее число, которое изменяется каждый день), и "пересмотр" или число патча. Я также видел их инвертированный (предоставление Главного. Незначительный. Пересмотр. Сборка), где сборка является последовательно увеличивающим числом от автоматизированной системы сборки.

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

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

http://msdn.microsoft.com/en-us/library/51ket42z.aspx

http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx

http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx

6

ответ дан Scott Dorman 12 November 2019 в 04:50

Другие вопросы по тегам:

c# .net assemblies versioning

Похожие вопросы:

score 24 · Accepted Answer

Некоторая хорошая информация от эта статья о блоге Suzanne Cook на MSDN (отправил 30.05.2003):

, Когда Изменить Версии Файла/Блока

, В первую очередь, версии файла и версии блока не должны совпадать друг с другом. Я рекомендую, чтобы версии файла изменились с каждой сборкой. Но, donвЂ™t изменяют версии блока с каждой сборкой именно так, что можно сказать различие между двумя версиями того же файла; используйте версию файла для этого. Решение, когда изменить версии блока, берет некоторое обсуждение типов сборок для рассмотрения: поставка и непоставка.

Непоставлющиеся Сборки
В целом, я рекомендую продолжать не поставляться, блок присваивает версию тому же между поставкой сборок. Это избегает проблем загрузки сборки со строгим именем из-за несоответствий версии. Некоторые люди предпочитают использовать политику издателя перенаправить новые версии блока для каждой сборки. Я рекомендую против который для непоставки сборок, однако: это doesnвЂ™t избегает всех загружающихся проблем. Например, если партнер копирует Ваше приложение с помощью xcopy, они не могут знать для установки политики издателя. Затем Ваше приложение будет повреждено для них, даже при том, что оно работает просто великолепно на Вашей машине.

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

Поставлющиеся Сборки
Что касается того, зависит ли itвЂ™s хорошая идея изменить ту версию для поставки сборок, это от того, как Вы хотите, чтобы привязка работала на конечных пользователей. Вы хотите, чтобы эти сборки были бок о бок или оперативные? Есть ли между двумя сборками много изменений? Они собираются повредить некоторых клиентов? Вы заботитесь, что это повреждает их (или Вы хотите вынудить пользователей использовать Ваши важные обновления)? Если да, необходимо рассмотреть постепенное увеличение версии блока. Но с другой стороны полагайте, что выполнение, который слишком много раз может замусорить userвЂ™s диск устаревшими блоками.

, Когда Вы Изменяете Свои Версии блока
Для изменения hardcoded версий на новую, я рекомендую установить переменную на версию в заголовочном файле и заменить жесткое кодирование в источниках с переменной. Затем выполните препроцессор во время сборки, чтобы вставить правильную версию. Я рекомендую изменить версии прямо после поставки, не прямо прежде, так, чтобы там был пора больше поймать ошибки из-за изменения.