Validate DLL Version
Completed
Hi,
My C#.NET Project include some dependent security DLL files. Somehow one programmer used an old version of DLL and uploaded to BitBucket and TeamCity compiled it with old DLL files which broke our Production system. How can we validate on TeamCity while building not to use any old version of any DLL included in a project if a new version is already deployed via previous releases.
e.g. Current Release DLL : 4.0.0.1
Previous Release DLL : 6.3.0.1
Current release is a bad release because it points to an old DLL. How can we validate during build phase at TeamCity (using MSBuild for build)?
Thanks in advance.
TeamCity User
Please sign in to leave a comment.
Hi,
TeamCity does not have any integrated way to check this automatically. Most dependency management systems allow to set either specific versions or ranges where the dependencies are valid, which is what most build systems use to validate this. Typically, you will still want to set this checks outside of TeamCity, though, because running this build on any local environment would still fail if the check is only implemented in teamcity. From your message, I've understood that 6.3.0.1 was the "old release" that was accidentally reused and "4.0.0.1" was the newer one, which is unlikely, so I'm assuming that I misunderstood and that 6.3.0.1 is the one which should have been used while 4.0.0.1 is the one that the user accidentally used, is this correct?
TeamCity offers its own dependency system that works in a parallel way. Through artifact dependencies: https://www.jetbrains.com/help/teamcity/artifact-dependencies.html you can tell TeamCity that a build should always use an artifact (of another build, it does not accept external ones). If you also join them via a snapshot dependency, it will always use the one from the same chain (if the prior build did not need to run due to no changes, it will simply pick up the last valid one that matches the rest of the conditions). It might work under some scenarios.
Of course, you can always implement your own scripting validation to check for DLL versions. It's also common to have a validation step before publishing where you set your own custom checks (typically through integration testing, but other checks can also be implemented via scripts), that way you have an extra safeguard before going to production.
Hope this helps.