0

When troubleshooting our applications, in many situations I cannot be sure what branch the assemblies originally come from, due to an imperfect release cycle and human error.

(We have quite a lot of different bugfix/feature/test/release branches etc. in our TFS).

The PDB-files can help sometimes, in a test environment at least, but sometimes they're missing or outdated / belong to assemblies from another branch.

So, I was trying to think of a way to include the source branch information inside the assembly directly.

Surprisingly, I could not easily find a straight forward way online to accomplish this.

My answer below explains my approach. I would be happy about feedback or alternative solutions.

marsze
  • 15,079
  • 5
  • 45
  • 61

1 Answers1

2

In short: I created a custom attribute that I put intoAssemblyInfo.cs. Inside the attribute's constructor, the server path for the current assembly is queried from TFS and compiled into it.

It's basically a combination of the following:

Can I add custom version strings to a .net DLL?

How do I get the path of the assembly the code is in?

Get TFS mapped folder of a local sub folder of the solution?

(Note: I cannot post the actual source code due to company restrictions, but I think it's pretty straight forward.)

To get the attribute's value later is unfortunately not as easy as getting the version number from the DLL-file's properties, but at least it is possible now to get the information I need with minimum effort. (I use a small PowerShell script for that.)

Community
  • 1
  • 1
marsze
  • 15,079
  • 5
  • 45
  • 61
  • 1
    I applaud your resourcefulness, but this will work until someone changes things within TFS... the reality is that you need to invest the time in tightening up your release cycle, and assigning blocks of build numbers to each branch. If you also implement TFS policies like every checkin needs to be linked with a work item then that also makes things easier. A bit of pain and discipline now will lead to a far better experience further down the track. – slugster Jul 28 '16 at 09:14
  • @slugster Unfortunately, the "real reality" is that I have zero control over my company and/or colleagues to do things as they *should* be done. On top of that we're a small company with a high workload. Your very useful comment is nevertheless very appreciated. Thank you. – marsze Jul 28 '16 at 09:27
  • 1
    You can use AssemblyInformationalVersion instead of a custom attribute: it will be displayed in Explorer's properties page of DLL. – Giulio Vian Jul 29 '16 at 08:58