Мне просто было интересно, как я могу автоматически увеличивать сборку (и версию?) Моих файлов с помощью Visual Studio (2005).
Если я просматриваю свойства, скажем, C:\Windows\notepad.exe, на вкладке «Версия» отображается «Версия файла: 5.1.2600.2180». Я хотел бы получить эти классные цифры и в версии моей dll, а не в версии 1.0.0.0, что, скажем прямо, немного скучновато.
Я пробовал кое-что, но, похоже, это не стандартная функциональность, или, может быть, я просто ищу не в том месте (как обычно).
Я работаю в основном с веб-проектами ....
Я посмотрел на оба:
и я не мог поверить, что такие большие усилия, чтобы что-то сделать, - это стандартная практика.
Обновлено: Насколько я могу судить, это не работает в VS2005 (http://www.codeproject.com/KB/dotnet/AutoIncrementVersion.aspx)
Есть ли какие-либо решения для этого, которые работают для проектов C++ в VS2005? Все ответы, похоже, относятся к .Net. Связанный вопрос. Спасибо
В проектах .Net Основной автоинкремент AssemblyVersion по умолчанию не работает. Вам нужно добавить <Deterministic> False </Deterministic> в csproj. См. Автоматическое управление версиями в Visual Studio 2017 (.NET Core)





Каждый раз, когда я делаю сборку, она автоматически увеличивает наименее значимую цифру.
Я понятия не имею, как обновить другие, но вы, по крайней мере, должны это уже видеть ...
VS отвечает за приращение последнего числа, которое обычно является номером сборки. Все остальное (то есть числа до этого) зависит от вас, потому что они представляют версию вашего приложения.
Огњен Шобајић: Не совсем верно. Схема нумерации Microsoft - major.minor.build.revision, например 1.0.4.7. Если вы установите для версии сборки что-то вроде «1.0. *», Тогда VS установит для вас номера сборки и ревизии. В этом случае сборка будет увеличиваться ежедневно, а ревизия - это количество секунд с полуночи, разделенное на 2.
Перейти к проекту | «Свойства», затем «Информация о сборке», а затем «Версия сборки» и поставьте * в последнее или предпоследнее поле (вы не можете автоматически увеличивать основные или второстепенные компоненты).
Чтобы получить номера версий, попробуйте
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
System.Reflection.AssemblyName assemblyName = assembly.GetName();
Version version = assemblyName.Version;
Чтобы установить номер версии, создайте / отредактируйте AssemblyInfo.cs
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]
Также в качестве примечания, третье число - это количество дней с 01.02.2000, а четвертое число - половина общего количества секунд в дне. Так что, если вы компилируете в полночь, он должен быть равен нулю.
откройте файл AssemblyInfo.cs и измените
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
к
[assembly: AssemblyVersion("1.0.*")]
//[assembly: AssemblyFileVersion("1.0.0.0")]
вы можете сделать это в IDE, перейдя в проект -> свойства -> информация о сборке
Однако это позволит вам только автоматически увеличивать версию сборки и даст вам
Assembly File Version: A wildcard ("*") is not allowed in this field
окно сообщения, если вы попытаетесь поместить * в поле версии файла.
Так что просто откройте файл assemblyinfo.cs и сделайте это вручную.
Да, я только что столкнулся с «Версия файла сборки: подстановочный знак (« * ») не разрешен в этом поле», поэтому ваш метод получил зеленую галочку: D
@ in.spite - это странно, у меня есть VS2005 pro, и, похоже, он работает так же, как vs 2008.
это работает: [сборка: AssemblyVersion ("1.0. *")] // [сборка: AssemblyFileVersion ("1.0.0.0")]
Вам нужно сделать это в файле AssemblyInfo.cs, как описано. К сожалению, диалоговое окно "Информация о сборке" выдает ошибку в наших интересах. Обсуждение здесь: connect.microsoft.com/VisualStudio/feedback/…
Кроме того, в IDE информации о сборке убедитесь, что вы удалили все, что меньше *, в вашей версии сборки. Он сообщает вам, что у вас есть «недопустимый формат версии», если вы этого не сделаете (например, 0 1 * 0 => сбой).
Менять номер AssemblyVersion во время цикла выпуска нежелательно. Вместо этого следует изменить AssemblyFileVersion. См. Мое сообщение в блоге по этой теме: philippetruche.wordpress.com/2008/08/12/… Также см. Отличное сообщение Сюзанны Кук о том, когда менять числа: blogs.msdn.com/b/suzcook/archive/2003/05/29/57148.aspx
Я буду осторожен, используя *, он перестанет работать 4 июня 2179 года, когда день станет 65536
Как этого добиться в новом формате csproj, где нет AssemblyInfo.cs?
@Shimmy: Добавить <Deterministic> False </Deterministic> в .csproj Автоматическое управление версиями в Visual Studio 2017 (.NET Core)
Установите номер версии на «1.0. *», И он автоматически заполнит последние два числа датой (в днях с некоторой точки) и временем (полсекунды с полуночи).
эй, если бы я прочитал это как следует вначале, я бы сэкономил много агро. Спасибо
Он находится в свойствах вашего проекта под Публиковать
Установка * в номере версии в AssemblyInfo или в свойствах проекта, как описано в других сообщениях, не работает со всеми версиями Visual Studio / .NET.
Афаик не работал в VS 2005 (но в VS 2003 и VS 2008). Для VS 2005 вы можете использовать следующее: Автоинкремент сборки версии Visual Studio 2005 и номера редакции во время компиляции.
Но имейте в виду, что автоматическое изменение номера версии не рекомендуется для сборок со строгими именами. Причина в том, что все ссылки на такую сборку должны обновляться каждый раз, когда указанная сборка перестраивается, поскольку ссылки на сборки со строгими именами всегда являются ссылкой на конкретную версию сборки. Сами Microsoft меняют номер версии сборок .NET Framework только в случае изменения интерфейсов. (NB: я все еще ищу ссылку в MSDN, где я это прочитал.)
Я думаю, что для любой версии VS вы можете поставить * только в полях Build или Revision. Я только что попробовал это с помощью VS 2005, и он отлично работает. Я не уверен, о чем говорит автор этой статьи о проекте кода.
Возможно, он вернулся с пакетом обновления, но я помню, что он не работал, когда я использовал VS 2005.
С 2005 не работает, поищу сервис пак и доложу.
Возможно, в MusiGenesis установлено дополнение, которое позволяет автоматически управлять версиями.
@divo: нет, я страдаю аддонфобией. У меня просто Visual Studio 2005 Professional SP1. Я никогда не видел проблем с *, но обычно увеличиваю вручную. Похоже на странную ошибку.
@ 0xA3 Я считаю, что ссылка MSDN, о которой вы говорите, - support.microsoft.com/kb/556041
В Visual Studio 2008 работает следующее.
Найдите файл AssemblyInfo.cs и найдите эти 2 строки:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
Вы можете попробовать изменить это на:
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion("1.0.*")]
Но это не даст вам желаемого результата, вы получите версию продукта 1.0. * и версию файла 1.0.0.0. Не то, что вы хотите!
Однако, если вы удалите вторую из этих строк и получите:
[assembly: AssemblyVersion("1.0.*")]
Затем компилятор установит версию файла, равную версии продукта, и вы получите желаемый результат - автоматически увеличивающийся продукт и версию файла, которые синхронизируются. Например. 1.0.3266.92689
Это работает так же хорошо, как и все остальное, и работает в VS2005. Я надеялся на какое-то рациональное число, например 1.0.1.56, вместо этого я получил 1.0.3266.30135, но, по крайней мере, оно увеличивается (хотя и на какое-то случайное число: D)
о, я только что прочитал: он автоматически заполнит последние два числа датой (в днях с некоторой точки) и временем (полсекунды с полуночи)
Хороший призыв к необходимости удалить атрибут AssemblyFileVersion, чтобы заставить это работать!
Я понимаю, что это старый вопрос, но хотел добавить этот комментарий для тех, кто нашел свой путь к этому ответу. Если вы увеличиваете AssemblyVersion, любой проект, использующий вашу dll, необходимо будет перекомпилировать. Однако, если вы сохраните AssemblyVersion таким же и увеличите AssemblyFileVersion отдельно, вы можете заменить новую dll без необходимости повторно компилировать то, что ее использует. Так что спросите себя: это просто новая сборка или я выпускаю новую версию?
@ DD59 «Сборка» - это количество дней с 1 января 2000 года; «Ревизия» - это секунды от полуночи разделенный на 2 (не полсекунды, а двухсекундные интервалы). Смотрите здесь: stackoverflow.com/a/3387167/11545
@onefootswill, но как бы вы увеличили версию файла отдельно от версии сборки, если вы можете указать только одну из них?
@Sinaesthetic Я думаю, вы не могли бы, если бы вы могли указать только один. Но я никогда не видел такого ограничения. В Assembly.cs или SharedAssemblyInfo.cs (в зависимости от обстоятельств) вы всегда можете указать оба.
есть идеи, почему это работает локально в Visual Studio, но, похоже, я получаю 1.0.0.0 в сборках TFS 2010?
Как были сгенерированы эти 3266,92689 двух чисел. 1.0.3266.92689
@Unbreakable 3266 - количество дней с 1-1-2000, 92689 - количество двухсекундных интервалов от полуночи.
@JustinKrejcha И все же в 24 часах всего 86400 секунд ... <музыка сумеречной зоны>
@ Ян двухсекундный интервал. Макс будет 43199 в 23:59:59. 3266 год будет чем-то в 2008 году. Я предполагаю, что Сэм выбрал какие-то случайные числа.
Отлично! Это было настолько полезно для меня, что я написал об этом в блоге: почти те же инструкции, что и выше, но с некоторыми снимками экрана для демонстрации: Technical-recipes.com/2018/…
На данный момент для моего приложения
string ver = Application.ProductVersion;
возвращает ver = 1.0.3251.27860
Значение 3251 - это количество дней с 01.01.2000. Я использую его, чтобы поставить дату создания версии на заставку моего приложения. Имея дело с пользователем, я могу спросить дату создания, которую легче сообщить, чем какое-то длинное число.
(Я один человек в отделе, поддерживающий небольшую компанию. Этот подход может не сработать для вас.)
Ваш номер скоро закончится. Я бы использовал yyddd, который представляет собой двухзначный год и трехзначный день с начала года, что составляет максимум 365. по крайней мере, ваша программа будет компилироваться до 2065 года. Тогда вы будете на пенсии и позволите кому-то другому выяснить, как они хотят с этим справиться. учитывая, что ваша программа на тот момент еще действует!
Используйте задачу AssemblyInfo из проекта MSBuild Community Tasks (http://msbuildtasks.tigris.org/) и интегрируйте ее в свой файл .csproj / .vbproj.
У него есть несколько опций, в том числе одна для привязки номера версии к дате и времени дня.
Рекомендуемые.
Установите надстройку Приращение версии сборки. Это дает вам больше контроля, чем опция *.
Только для VS2005 / 2008, с бета-версией для VS2010
Я использую Автоматические версии для VS2012, и он работает очень хорошо.
Другой вариант изменения номеров версий в каждой сборке - использовать задачу Версия для MSBuild.Community.Tasks. Просто скачайте их установщик, установите его, затем адаптируйте следующий код и вставьте его после <Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> в свой файл .csproj:
<Import Project = "$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<Target Name = "BeforeBuild">
<Version VersionFile = "Properties\version.txt" Major = "1" Minor = "0" BuildType = "Automatic" StartDate = "12/31/2009" RevisionType = "BuildIncrement">
<Output TaskParameter = "Major" PropertyName = "Major" />
<Output TaskParameter = "Minor" PropertyName = "Minor" />
<Output TaskParameter = "Build" PropertyName = "Build" />
<Output TaskParameter = "Revision" PropertyName = "Revision" />
</Version>
<AssemblyInfo CodeLanguage = "CS"
OutputFile = "Properties\VersionInfo.cs"
AssemblyVersion = "$(Major).$(Minor)"
AssemblyFileVersion = "$(Major).$(Minor).$(Build).$(Revision)" />
</Target>
Примечание: Адаптируйте свойство StartDate к вашему языку. В настоящее время он не использует инвариантный язык и региональные параметры.
Для третьей сборки от 14 января 2010 г. будет создан VersionInfo.cs со следующим содержимым:
[assembly: AssemblyVersion("1.0")]
[assembly: AssemblyFileVersion("1.0.14.2")]
Затем этот файл должен быть добавлен в проект (через Добавить существующий элемент), а строки AssemblyVersion и AssemblyFileVersion должны быть удалены из AssemblyInfo.cs.
Различные алгоритмы изменения компонентов версии описаны в $(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.chm и Свойства версии.
Это лучший способ обойти тот ужасный факт, что структуры FileVersion используют 16-битные целые числа.
У меня возникли проблемы с установкой в VS2012 с помощью Package Console, поэтому рекомендую использовать загруженные ночные установщики msi по адресу github.com/loresoft/msbuildtasks/downloads. Работает копировать / вставлять из вышеперечисленного. Спасибо!
После того, как это было отклонено и отредактировано в этом сообщении: «Вы также можете проверить этот loresoft.com/projects/msbuildtasks/…, он может улучшить базовую функциональность, описанную ранее».
Это не жизнеспособное решение для тех, кто использует TFS. В конечном итоге это добавит ожидающие изменения в файлы VersionInfo.cs и version.txt. Для меня нежелательно иметь незавершенное редактирование для каждой сборки.
@JDennis см. здесь для советов по управлению версиями TFS ...
Я придумал решение, подобное христианам, но вне зависимости от задач сообщества MSBuild, это не вариант для меня, поскольку я не хочу устанавливать эти задачи для всех наших разработчиков.
Я генерирую код и компилирую его в сборку и хочу автоматически увеличивать номера версий. Однако я не могу использовать трюк VS 6.0. * AssemblyVersion, поскольку он автоматически увеличивает номера сборок каждый день и нарушает совместимость со сборками, использующими более старый номер сборки. Вместо этого я хочу иметь жестко запрограммированную AssemblyVersion, но автоматически увеличивающуюся AssemblyFileVersion. Я добился этого, указав AssemblyVersion в AssemblyInfo.cs и сгенерировав VersionInfo.cs в MSBuild следующим образом:
<PropertyGroup>
<Year>$([System.DateTime]::Now.ToString("yy"))</Year>
<Month>$([System.DateTime]::Now.ToString("MM"))</Month>
<Date>$([System.DateTime]::Now.ToString("dd"))</Date>
<Time>$([System.DateTime]::Now.ToString("HHmm"))</Time>
<AssemblyFileVersionAttribute>[assembly:System.Reflection.AssemblyFileVersion("$(Year).$(Month).$(Date).$(Time)")]</AssemblyFileVersionAttribute>
</PropertyGroup>
<Target Name = "BeforeBuild">
<WriteLinesToFile File = "Properties\VersionInfo.cs" Lines = "$(AssemblyFileVersionAttribute)" Overwrite = "true">
</WriteLinesToFile>
</Target>
Будет создан файл VersionInfo.cs с атрибутом Assembly для AssemblyFileVersion, где версия соответствует схеме YY.MM.DD.TTTT с датой сборки. Вы должны включить этот файл в свой проект и построить с ним.
Поддерживает ли MSBuild переменные? Было бы лучше поместить [System.DateTime]::Now в один, иначе возникнет состояние гонки, которое может привести к использованию старого номера сборки при строительстве около полуночи.
Вы определили эти четыре свойства вместо того, чтобы объединить их в одном DateTime.ToString для демонстрационных целей, или есть особая причина?
Если ваше событие BeforeBuild не срабатывает в VS2017, проверьте stackoverflow.com/questions/43921992/…
Это решение лучше всего подходит из всех приведенных здесь ответов. Однако проблема в том, что отметка времени (или содержимое файла versioninfo.cs) не обновляется, если вы собираете проект во второй раз, что должно привести к другой минуте. Если я закрою и перезагружу проект, отметка времени обновится. Это ошибка MSBuild? @Boog
Можно ли в этих разметках производить какие-либо операции? С $([System.DateTime]::Today.Year - 2010) выдает ошибку невозможно вычислить выражение "" 24/08/2020 00:00:00 ". Год - 2010". Не удается найти метод SystemDateTime.Year -2009.
Это отличное решение для тех, кто хочет подписаться на Calver! +1 от меня. Одна вещь, которую я бы упростил, - это переменные: <Date>$([System.DateTime]::Now.ToString("yyyy.M.d.HHmm"))</Date>. Работает как шарм.
Чтобы получить увеличивающуюся (DateTime) информацию в свойстве AssemblyFileVersion, которое имеет то преимущество, что не нарушает никаких зависимостей.
Основываясь на решении Boog (не сработало для меня, возможно, из-за VS2008?), Вы можете использовать комбинацию события перед сборкой, генерирующего файл, добавляя этот файл (включая его свойства версии), а затем используя способ считывания эти ценности снова. Это..
Предварительное событие:
echo [assembly:System.Reflection.AssemblyFileVersion("%date:~-4,4%.%date:~-7,2%%date:~-10,2%.%time:~0,2%%time:~3,2%.%time:~-5,2%")] > $(ProjectDir)Properties\VersionInfo.cs
Включите полученный файл VersionInfo.cs (подпапка Properties) в свой проект.
Код для возврата даты (от лет до секунд):
var version = assembly.GetName().Version;
var fileVersionString = System.Diagnostics.FileVersionInfo.GetVersionInfo(assembly.Location).FileVersion;
Version fileVersion = new Version(fileVersionString);
var buildDateTime = new DateTime(fileVersion.Major, fileVersion.Minor/100, fileVersion.Minor%100, fileVersion.Build/100, fileVersion.Build%100, fileVersion.Revision);
Не очень удобно .. также я не знаю, создает ли он много принудительных пересборок (поскольку файл всегда изменяется).
Вы можете сделать его умнее, например, если вы обновляете файл VersionInfo.cs каждые несколько минут / часов (используя временный файл и затем копируя / перезаписывая реальный VersionInfo.cs, если обнаруживается достаточно большое изменение). Однажды я сделал это довольно успешно.
Работает отлично. Однако это регулярное выражение% date: ~ -4,4%.% Date: ~ -7,2 %% date: ~ -10,2%.% Time: ~ 0,2 %% time: ~ 3,2 %.% time: ~ -5,2% "слишком сложно.
Возможно, для этой задачи вы можете использовать такой код:
private bool IncreaseFileVersionBuild()
{
if (System.Diagnostics.Debugger.IsAttached)
{
try
{
var fi = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory).Parent.Parent.GetDirectories("Properties")[0].GetFiles("AssemblyInfo.cs")[0];
var ve = System.Diagnostics.FileVersionInfo.GetVersionInfo(System.Reflection.Assembly.GetExecutingAssembly().Location);
string ol = ve.FileMajorPart.ToString() + "." + ve.FileMinorPart.ToString() + "." + ve.FileBuildPart.ToString() + "." + ve.FilePrivatePart.ToString();
string ne = ve.FileMajorPart.ToString() + "." + ve.FileMinorPart.ToString() + "." + (ve.FileBuildPart + 1).ToString() + "." + ve.FilePrivatePart.ToString();
System.IO.File.WriteAllText(fi.FullName, System.IO.File.ReadAllText(fi.FullName).Replace("[assembly: AssemblyFileVersion(\"" + ol + "\")]", "[assembly: AssemblyFileVersion(\"" + ne + "\")]"));
return true;
}
catch
{
return false;
}
}
return false;
}
и вызвать его из загрузки формы. С помощью этого кода вы можете обновить любую часть информации о файле в AssemblyInfo.cs (но вы должны использовать «стандартную» структуру каталогов).
Изменение AssemblyInfo работает в VS2012. Кажется странным, что в Visual Studio для этого больше нет поддержки, можно подумать, что это основная часть процесса сборки / выпуска.
AssemblyInfoUtil. Бесплатно. Открытый источник.
Я использую этот подход https://stackoverflow.com/a/827209/3975786, помещая шаблон T4 в «Элементы решения» и используя его с «Добавить как ссылку» в каждом проекте.
Торт поддерживает исправление файлов AssemblyInfo. С тортом в руках у вас есть бесконечное количество способов реализовать автоматическое приращение версии.
Простой пример увеличения версии, такой как компилятор C#:
Setup(() =>
{
// Executed BEFORE the first task.
var datetimeNow = DateTime.Now;
var daysPart = (datetimeNow - new DateTime(2000, 1, 1)).Days;
var secondsPart = (long)datetimeNow.TimeOfDay.TotalSeconds/2;
var assemblyInfo = new AssemblyInfoSettings
{
Version = "3.0.0.0",
FileVersion = string.Format("3.0.{0}.{1}", daysPart, secondsPart)
};
CreateAssemblyInfo("MyProject/Properties/AssemblyInfo.cs", assemblyInfo);
});
Здесь:
Учтите, что вы можете патчить не только версии, но и а также вся другая необходимая информация.
{major}.{year}.1{date}.1{time}Этот экспериментальный, но мне он нравится. На основе Джеффа Этвуда @ CodingHorror (связь).
В результате номер версии становится 1.2016.10709.11641 (то есть 2016-07-09 16:41), что позволяет
1)Добавьте новый элемент в свой проект, выберите «Общие» -> «Текстовый шаблон», назовите его как-нибудь вроде CustomVersionNumber и (если применимо) закомментируйте AssemblyVersion и AssemblyFileVersion в Properties/AssemblyInfo.cs.
Затем при сохранении этого файла или построении проекта будет повторно сгенерирован файл .cs, расположенный как подпункт в созданном файле .tt.
<#@ template language = "C#" #>
<#@ assembly name = "System.Core" #>
<#@ import namespace = "System.Linq" #>
//
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.
//
using System.Reflection;
<#
var date = DateTime.Now;
int major = 1;
int minor = date.Year;
int build = 10000 + int.Parse(date.ToString("MMdd"));
int revision = 10000 + int.Parse(date.ToString("HHmm"));
#>
[assembly: AssemblyVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
[assembly: AssemblyFileVersion("<#= $"{major}.{minor}.{build}.{revision}" #>")]
Вы не компилируете свою программу каждую минуту и не развертываете более одного раза в день, поэтому технически временная часть излишне занимает ценную информацию, я бы использовал 1-й и 2-й для основных второстепенных и просто использовал 3-е число для даты yyddd (год из двух цифр + ддд день с начала того же года) и оставьте 4-й для номера инкрементной сборки.
Может быть, уже слишком поздно отвечать здесь, но надеюсь, что это решит чью-то беспокойную проблему.
Автоматический способ изменить версию сборки всех ваших проектов с помощью сценария PowerShell. эта статья решит многие ваши проблемы.
Единственная проблема с PS - он медленно реагирует и требует настройки для его работы. Я бы пошел с небольшим исполняемым файлом, файлом tt4 или даже встроенным кодом, который, как мне кажется, любой программист может написать одним способом.
Существует расширение Visual Studio Автоматические версии, которое поддерживает Visual Studio (2012, 2013, 2015) 2017 и 2019.
Итак, я удалил его и могу сказать даже больше ... он изменяет исходный файл csproj. Я считаю, что это очень проблематичное расширение.
@Maxim Попробуйте последнюю версию, она должна работать на VS 2017
Отличная утилита. У меня отлично работает в vs2017. Документация могла бы быть немного понятнее, но установите ее (через сайт), а затем установите MSBuild через Nuget, примените к небольшому проекту, поиграйте и соберите. Хороший. Ответ @ Boog не сработал для меня, хотя он сказал именно то, чего я пытался достичь.
Я создал приложение для автоматического увеличения версии файла.
добавьте следующую строку в командную строку события перед сборкой
C: \ temp \ IncrementFileVersion.exe $ (SolutionDir) \ Properties \ AssemblyInfo.cs
Построить проект
Для простоты приложение выдает сообщения только в случае ошибки. Чтобы убедиться, что все работает нормально, вам нужно будет проверить версию файла в разделе «Информация о сборке».
Примечание. Вам нужно будет перезагрузить решение в Visual Studio для кнопки «Информация о сборке», чтобы заполнить поля, однако ваш выходной файл будет иметь обновленную версию.
Для предложений и запросов, пожалуйста, напишите мне по адресу [email protected]
Мне было недостаточно добавить
[assembly: AssemblyVersion("1.0.*")]
При построении он выдает мне эту ошибку
The specified version string does not conform to the required format
Формат был окончательно принят после того, как я установил Deterministic на False в project.csproj.
<Deterministic>false</Deterministic>
По какой-то причине установка Deterministic на False испортила мой файл конфигурации, загрузив его и сохранив в разных местах.
Я настраиваю событие после сборки, чтобы увеличить номер версии:
Это вызывает сценарий PowerShell с именем autoincrement_version.ps1, передающий в качестве аргумента путь к AssemblyInfo.cs.
if $(ConfigurationName) == Release (
PowerShell -ExecutionPolicy RemoteSigned $(ProjectDir)autoincrement_version.ps1 '$(ProjectDir)My Project\AssemblyInfo.cs'
)
Он автоматически увеличивает номер версии с помощью Regex
param( [string]$file );
$regex_revision = '(?<=Version\("(?:\d+\.)+)(\d+)(? = "\))'
$found = (Get-Content $file) | Select-String -Pattern $regex_revision
$revision = $found.matches[0].value
$new_revision = [int]$revision + 1
(Get-Content $file) -replace $regex_revision, $new_revision | Set-Content $file -Encoding UTF8
Любой, кто использует Tortoise Subversion, может связать один из номеров своей версии с номером версии Subversion исходного кода. Я считаю это очень полезным (аудиторам это тоже нравится!). Вы делаете это, вызывая утилиту WCREV в вашей предварительной сборке и генерируя свой AssemblyInfo.cs из шаблона.
Если ваш шаблон называется AssemblyInfo.wcrev и находится в обычном каталоге AssemblyInfo.cs, а черепаха находится в каталоге установки по умолчанию, то ваша команда Pre-Build выглядит следующим образом (N.B. Все в одной строке):
"C:\Program Files\TortoiseSVN\bin\SubWCRev.exe" "$(ProjectDir)." "$(ProjectDir)Properties\AssemblyInfo.wcrev" "$(ProjectDir)Properties\AssemblyInfo.cs"
Файл шаблона будет включать строку подстановки токена wcrev: $ WCREV $
.
например,
[assembly: AssemblyFileVersion("1.0.0.$WCREV$")]
Примечание:
Поскольку ваш AssemblyInfo.cs теперь сгенерирован, вы не хотите, чтобы он контролировал версию.
wild card, похоже, работает только для AssemblyVersion, но не для AssemblyFileVersion в VS 2005