Jason Shirk (@lzybkr) Please clarify - currently git --git-dir=".git" describe --dirty --abbrev=60 return v6.0.0-alpha.18-60-gb09e9b570c757b9869f454276aa708eac307f5b1 where last part is a hash - do you want change formatting? v6.0.0-alpha.18-60 Commit Hash: gb09e9b570c757b9869f454276aa708eac307f5b1

I'm always a fan of better formatting.

I suggest reading the documentation on describe, and we might consider using --long to always get the hash.

Note that the g is not part of the hash, the format (with --long) is {tag}-{# of commits past tag}-g{hash of head}.

We would parse the long formatted "git describe" and output in the desired form, ex.:
Version: v6.0.0-alpha.18 Commits: 60 Commit Hash: b09e9b570c757b9869f454276aa708eac307f5b1

Sounds good, though I would omit Commits if it is 0 (which will be the common case) and maybe use the phrase Additional Commits.

Jason Shirk (@lzybkr) powershell.version is still used in Install-PowerShellRemoting.ps1.

I see #2671 Should we fix the script here? If yes how can we fix this? Can we use there PSVersionTable.PSVersion?

/cc Mike Richmond (@mirichmo)

I added commit to fix #3739

Ilya (@iSazonov) thanks for fixing this. The hard-coded alpha string caused me huge effort in beta.1 release.
I have 2 comments:

1. Could you please resolve the conflicts?
2. If you search the usage of powershell.version, you will find it appears in following files:

E:\PowerShell\.gitignore
E:\PowerShell\.spelling
E:\PowerShell\build.psm1
E:\PowerShell\build.sh
E:\PowerShell\build.sh
E:\PowerShell\src\powershell-native\Install-PowerShellRemoting.ps1
E:\PowerShell\src\powershell-unix\powershell-unix.csproj
E:\PowerShell\src\powershell-win-core\powershell-win-core.csproj
E:\PowerShell\src\System.Management.Automation\engine\PSVersionInfo.cs
E:\PowerShell\src\System.Management.Automation\engine\PSVersionInfo.cs
E:\PowerShell\test\powershell\Host\PSVersionTable.Tests.ps1

Some of those files are not updated in this PR. I think all appearances of powershell.version need to be reviewed and updated.

This is the third conflict over the past 24 hours in build.psm1 😄 - I'll resolve tomorrow.

I use powershell.version file in tests. So you might have to leave it in .gitignore

I'm afraid that I won't be able to fix build.sh - can I delegate this anybody?

Ilya (@iSazonov) Sorry that I have to change build.psm1 many times in the past day -- obviously our release process and test infrastructure are still far away from perfect 😦

As for build.sh, writing an equivalent bash script to do the same would be (1) not easy (2) hard to maintain 2 scripts for the same thing in future. One option is to extract this logic and write C# code to do it, like the existing ResGen and TypeCatalogGen. Then we can just call dotnet run from both powershell script and bash script.

I'm not sure how many people are using build.sh honestly, and not really sure if this worth the effort.
Steve Lee (@SteveL-MSFT) Joey Aiello (@joeyaiello) Jason Shirk (@lzybkr) do we have any data to show how important build.sh is? Can we just remove that support?

appveyor temporaryly failed - I restart.

I only fix but don't test 'Install-PowerShellRemoting.ps1'.

Ilya (@iSazonov) - I ran across this relevant blog post which suggests an assembly attribute that we should also use.

I think we can ignore the part in that blog post about finding the sha without git - we've been using git to do this already with no complaints.

This is exactly what we use. Used to use GitVersion but now we're doing our own computation of build metadata:

Get-FileVersionInfo P:\Repositories\BuildResults\Foo_Master_CompleteBuild\5.2.0.105\64BitDevelopment
\Release\Foo.dll | ForEach-Object ProductVersion

5.2.0+105.Branch.master.Sha.31e45082cd1093133b6687dd172daa04b2a10940.Built.20170505T1739

And we do use git to get the SHA1, branch, etc. This is the function we use:

function GetGitBuildMetadata([string]$SemVer, [string]$Revision) {
    $timestamp = Get-Date -Format yyyyMMddTHHmm
    $sha1   = git rev-parse --verify HEAD
    $branch = git rev-parse --abbrev-ref HEAD
    if (!$branch -or ($branch -eq 'HEAD')) {
        if ($env:BUILD_SOURCEBRANCH) {
            $branch = $env:BUILD_SOURCEBRANCH.Trim().Replace("refs/heads/", "").Replace("refs/","")
        }
        else {
            $branch = 'unknown'
        }
    }

    $prereleaseTag = if ($branch -notmatch 'master|release') { '-prerelease' } else { '' }

    $metadata = "${SemVer}${prereleaseTag}+${Revision}.Branch.${branch}.Sha.${sha1}.Built.${timestamp}"
    $metadata
}

Closed the PR by accident 🤕

Dongbo Wang (@daxian-dbw) GetVersion isn't still ported 😕 GitTools/GitVersion#1175

Dongbo Wang (@daxian-dbw) I don't believe that tampering with version attributes of a file by itself is a security concern, since are many other ways of file tampering for malicious purposes. The way to guard against file tampering is with application white listing (and black listing for deprecated versions) where approved file versions are validated through file signing or catalog signing.

I took the next step. Now all projects have common properties and assemblies get version from Start-PSBuild.

This PR is getting too complex, and I think we'd better break it down.
We need a conclusion about how to dynamically generate PSVersion and GitCommitId. There are three proposals so far:

1. Add script in Start-PSBuild to parse git describe string, and generate c# source file to keep the information. Pros: easy to implement. Cons: (1) hard to bring build.sh up-to-date (e.g. hard to write the equivalent bash script, hard to maintain two scripts that do the same thing) (2) make it harder to eventually build the powershell core in Visual Studio as we have another necessary step burnt into the script.
2. Add a C# project, maybe named PSVersionGen, like ResGen and TypeCatalogGen to do the code generation. Pros: (1) easy to update build.sh, and only one implementation to maintain. (2) it may be easier to eventually build the powershell core in Visual Studio 2017. Cons: a bit harder to implement comparing using the script.
3. Dynamically generate AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute via MSBuild, and change code in PSVersionInfo.cs to parse the FileVersion string to get PSVersion and GitCommitId when PSVersionTable is generated for the first time. Pros: clean, no magical code generation at build time, maybe the easiest to move to Visual Studio 2017 in future. Cons: hard to implement -- csproj changes + more robust logic to parse FileVersion in production code. The MSBuild part definitely need extra research and trial/error (build + NuGet package geneation both depend on csproj. A side topic, .NET Core team use different csproj files for build and package, maybe we should go that direction.)

We need to draw to a conclusion first to know what work items would be. Then we break down the work items so that they can be addressed in multiple PRs, instead of one PR with too many changes.

I vote for NO.3 proposal. Jason Shirk (@lzybkr) Ilya (@iSazonov) please share your opinions.

In brief I agree with NO.3

Perhaps we should create a Meta Issue to split the work on small pieces:
Meta Issue - "Move Start-PSBuild to MSBuild":

• Clean up Start-PSBuild from FullClr code and old code.
• Generate MSBuild variables with version strings based on Git tags
• Move common csproj properties to a common targets file.
• Unify AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute for all assemblies.
• Fix PSVersionInfo.cs to parse the FileVersion string or/and use MSBuild variables with version.
• Use different csproj files for build and package.
• ???

The PR shouldn't be merged - it is only for tracking multiple changes. We split the PR on some light-weight PRs.
There we are trying set assembly attributes by MSBuild based on git version tag and also expose the version to PSVersion table and PowerShell startup banner.
Some Microsoft projects (Roslin, CoreFX/CoreCLR ...) use such version format.

Jason Shirk (@lzybkr) Dongbo Wang (@daxian-dbw) Could you please comment? How can we resolve the conflict with telemetry?

The work is covered b #4863. So close this PR.