Getting package version

I would like to print out my package version, including the resolved $(GitVersion) macro, in my result listener files.

I want the version info to be as accurate as possible, whether I’m running an installed package, or from locally built source code. The version seen in the Package Manager doesn’t get updated during local debug builds, so I’d rather not parse the version from there.

My idea is to use a pre-build event to generate the version string, probably by calling OpenTAP’s PackageDefExt.FromInputXml, or maybe GitVersionCalulator (neither of which are currently public). I would save that version string to an embedded resource text file, which can then be read at runtime.

Thoughts anyone? Has this been tackled already?

1 Like

@david-wsd PackageDefExt isn’t public, but you can do something mostly the same with PackageDef.

First, add a reference to OpenTap.Package.dll:

var package = PackageDef.FromXml(fileName);
var version = package.Version;   

I tried it out, the method appears to only deserialize the xml, without resolving the GitVersion macro. So the deserialized Version is null. I’m hoping to be able to resolve GitVersion during every build.

I just realized there is a simple and bulletproof way to do this: invoke package building in all build configs (including Debug), rather than only in Release mode. Another benefit is that the Package Manager immediately reflects the newly built version. The downside is that .tappackage files start to accumulate quickly.

What do you think @brennen_direnzo, is building packages in all build configs a strange practice?

In which build configs do you invoke .TapPackage creation?
  • Release only
  • Release and Debug
  • Other (feel free to explain in a reply)

0 voters

Hmm ok. I guess that doesn’t get set until the Package is built. So, you could create the .TapPackage with Debug builds. You would also need to include the pdb files if you actually wanted to debug, so you would have two different Package.xml files. That would be one additional downside. You could also consider leveraging what we use to calculate the GitVersion:

Thanks @brennen_direnzo. Good thought on the pdb files.

Would you guys be open to making GitVersionCalulator a public class? That would certainly be a more lightweight solution than creating packages every build.

1 Like

Yeah, I don’t see why not. Or at least something similar that allows you to easily get the version. Can you submit a feature request here:[assignee_id]=&issue[milestone_id]=

Thanks @brennen_direnzo, I’ve submitted the request here

1 Like