mirror of
https://github.com/microsoft/terminal.git
synced 2025-12-10 17:53:06 -06:00
b0396f1741
While working on another PR related to this I noticed that my VS generates `.vcxproj` files that are a bit different to the ones we have. This commit is a quick search & replace of all our project files to make (primarily) their `ToolsVersion` more in line with what VS does itself: No `ToolsVersion` for `.vcxproj`, `ToolsVersion="15.0"` for `.csproj` and `ToolsVersion="4.0"` for `.filters` files.
24 lines
1.3 KiB
XML
24 lines
1.3 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
|
<!-- This file is read by XES, which we use in our Release builds. -->
|
|
<PropertyGroup Label="Version">
|
|
<!--
|
|
The Windows 11 build is going to have the same package name, so it *must* have a different version.
|
|
The easiest way for us to do this is to add 1 to the revision field.
|
|
In short, for a given Terminal build 1.11, we will emit two different versions (assume this is build
|
|
4 on day 23 of the year):
|
|
- 1.11.234.0 for Windows 10
|
|
- 1.11.235.0 for Windows 11
|
|
This presents a potential for conflicts if we want to ship two builds produced back to back on the
|
|
same day... which is terribly unlikely.
|
|
-->
|
|
<VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>
|
|
|
|
<XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
|
|
<XesBaseYearForStoreVersion>2022</XesBaseYearForStoreVersion>
|
|
<VersionMajor>1</VersionMajor>
|
|
<VersionMinor>16</VersionMinor>
|
|
<VersionInfoProductName>Windows Terminal</VersionInfoProductName>
|
|
</PropertyGroup>
|
|
</Project>
|