4

I am working with the TFS2017 build process and am having issues with versioning the assemblies. I am using the dotnet build task, command is set to build, Projects is set to **/*.sln and arguments set to --configuration $(BuildConfiguration) /p:Version=$(Build.BuildNumber)

When looking at the TFS build log the right command is executed (see below)

"C:\Program Files\dotnet\dotnet.exe" build C:\_agent\_work\13\s\*nameofsolution*.sln --configuration Release /p:Version=1100.1.0.0005

However the version of the assembly (File Version and Product Version) show as 1.0.0.

In the csproj file there is no <Version> element.

When I run the above generate command on the build server as the build agent user the assembly is versioned correctly. Is there something that I am missing in my csproj or as part of the solution properties?

davefester
  • 41
  • 4
  • maybe this answer will help (https://stackoverflow.com/questions/43274254/setting-the-version-number-for-net-core-projects-csproj-not-json-projects) – markorial Jan 18 '19 at 12:12
  • @markorial the issue is that running the generated command from the build log file produces the a dll with the correct versioning but from the build agent the dll is not versioned. The response you posted seems to be a work around by using version-prefix and version-suffix. – davefester Jan 18 '19 at 14:41
  • Ok, hmm now a few questions. Which type of build step are you using for this? Have you tried using a msbuild step with property parameters to see if it will version in properly? – markorial Jan 19 '19 at 09:36
  • I’m using the dotnet build task version 1.*. There would be no reason to run the msbuild task as the command that is generated for the build agent to run works and versions the dll correctly when ran in the build server. – davefester Jan 20 '19 at 12:31
  • just looked at the docs and the cli command for version is `dotnet build -p:Version=1.2.3.4` i do not know but maybe vs2017 is not interpreting it right with the `/p:Version=` within the task correctly – markorial Jan 20 '19 at 12:38
  • Tried both / and - both produced the same expected result when ran on the build server from the command line. Both were used in the build task and didn’t version the dll. I have read all the documentation and the msbuild parameters. – davefester Jan 20 '19 at 19:06
  • last thing i can think of is that i had to add a dotnet runtime installer on one of my projects as the first step in order for some specific build calls to pass because they were dependent on the dotnet version we used. if that does not help then then i am out of ideas since i cannot replicate your issue on my end. Sorry if i was not more help – markorial Jan 20 '19 at 19:36
  • dotnet is installed and the correct version is being called by the build tasks. I believe there is an issue with the way the projects/solutions may have been set up. I created a test .net standard solution, with a unit test project, replicated the build steps and the dll was versioned correctly for the test solution to replicate the issue. – davefester Jan 20 '19 at 19:40
  • i had the correct version installed as well but for some reason the dotnet task called dotnet from the working folder and i have no clue why it then ignored the environment path rather it looked at his own dotnet version that was there. and that was breaking my build after i added the runtime install step my issues went away. admittedly there are things i still do not understand how it compiles somethings and from where. – markorial Jan 20 '19 at 19:46
  • Definitely isn’t running from the build folder, like I said created a completely different build for a different solution and it worked correctly, called dotnet.exe from the installed directory. – davefester Jan 20 '19 at 19:50
  • sorry i was not more help. hope you find a solution – markorial Jan 20 '19 at 19:55
  • 1
    @davefester did you ever resolve this, having the exact same issue now :( – Phil Jun 21 '19 at 09:16

2 Answers2

4

TL&DR

Make sure your subsequent build steps on your build server, are passing any necessary --no-build flags to prevent the dotnet command from recompiling by default!!! E.G.:

dotnet test my.csproj --no-build --no-restore
dotnet publish my.csproj --output mydir --no-build --no-restore

OK! I ran into this exact issue when using TeamCity for my build server. I would run through the build process via TeamCity, and my output nuget file would contain DLLs with the default version 1.0.0.0. But when I would look at the build logs, I would take the dotnet build command from the log file, run it on the server, and I would get versioned dlls in the bin directories.

Here's what I found out was happening. In my build pipeline, after the build command, I was also running other commands like dotnet test and dotnet publish. These commands, by default, will recompile the solution/project without the build arguments! In addition they will recompile any referenced dependency projects.

EverPresent
  • 1,903
  • 17
  • 21
3

I had the same issue and found out that if .csproj contains <GenerateAssemblyInfo>false</GenerateAssemblyInfo> the version parameter is completely ignored. See the open issue associated with that. Making it true or removing this item should resolve the problem.

Andrei Orlov
  • 858
  • 3
  • 12
  • 24