re #630 - optionally allows /updateassemblyinfofilename to be generated

[Philo]

Adds argument /ensureassemblyinfo, when specified and /updateassemblyinfofilename is specified and does not exist we will generate a template of the assembly info file containing only *Version
attributes in either cs, fs, vb allowing the version values to be replaced.

[gep13]

@JakeGinnivan what are your thoughts on this one? Personally I was thinking that this would GitVersion away from it's core functionality.

[JakeGinnivan]

Yeah unsure about it.

It only supports adding an assemblyInfo file in the root of the repo which is probably too limiting. I also don't like the idea of a file missing until you run GitVersion in your repo. Any reason the Task doesn't work for you, because it has this functionality because it is inside the MSBuild pipeline?

[Philo]

The primary reason for not considering the MSBuild task is a lack of support for dynamic repositories, could this be implemented, perhaps by adding repo url, branch and commit id to the build pipeline somehow?

Coming from a rake build background I'm not a fan of modifying msbuild xml as it tends is likely to lead to confusion within the team as it is less transparent than an "external" build script/process.

The specific implementation would solve a specific issue we have with our build process and using GitVersion, that we would have to commit a file to the repo that we have historically always avoided adding as it is auto-generated from our build scripts (rake).

I'm happy to discuss further, either make refinements or consider looking at implementing dynamic repositories within the MSBuild task assuming there are no blocking issues with doing so.

[Philo]

@JakeGinnivan, I have tried the GitVersionTask as suggested, and while it stamps the version on the assemblies as I would need am I still left with 2 issues.

• No support for dynamic repositories (our usual CI environment is Teamcity, I used appveyor for testing)
• With the GitVersionTask I can not create a valid symbols package due to the auto-generated version assembly file not being included in the project itself. (see Symbols package fails to publish when using GitVersionTask due to missing file #636)

A very typical case for using GitVersion is for library packages or mini frameworks (one of my core reasons for wanting to use it to manage versioning across a team), it is important for us to be able to generate symbols packages for debugging. Relying on something like dotPeek would be an alternative but I wouldnt want to have to dependent on an external tool.

In the worst case I can live without symbols, based on @SimonCropp reasons.

I can appreciate not wanting to pollute GitVersionExe with an answer to every problem, however this is really just an extension to the existing /updateassemblyinfo task.

At the moment if you specify /updateassemblyinfo file_that_doesnt_exist.cs then the fallback is to search for AssemblyInfo.cs files and just update them, I would argue this is not the correct fallback as the user has specifically requested that an individual file be updated, if that file doesnt exist then either an error is thrown or nothing is updated.

[JakeGinnivan]

Yeah completely understand. I think it's fine we bring this in, the issue is it doesn't quite fit in with what we have now:

• /updateassemblyinfo file.cs actually is not an absolute path, it looks for all assemblyinfo.cs files
• /ensureAssemblyInfo creates a single file in the root of the repository, it is too restrictive

I think maybe it should be a config setting:

assemblyInfoFiles:
  - src\Proj\Properties\VersionInfo.cs
  - src\Proj2\Properties\VersionInfo.cs

Then we change gitversion to append those to the files found by the scan and then it should always create them if they do not exist.

Thoughts?

[Philo]

@JakeGinnivan, I agree about /ensureassemblyinfo being far too restrictive, I actually never thought about this and was focused on re-using as much of the existing file modification code as possible and not altering or breaking any existing execution scenarios.

I'll take a look at adding to the config options for specifying these as additional assembly info files.

[JakeGinnivan]

I have tested /updateassemblyinfo path/to/versionfile.cs works just fine. If you have a single version file just make a change that if it cannot be found that path is created relative to the working directory

The config can be done later

[JakeGinnivan]

Do you want me to create a new issue to track this?

[Philo]

@JakeGinnivan, I will try and get some time in the next few days to update this