I'd like to configure .net code inspection for my build plan. However, standard TeamCity way of doing that is creating a build step and specify a particular solution to run the inspection on.
Our build plan is an msbuild script that builds 20+ solutions (and the list is quite frequently updated), therefore it would be easier to maintain the list in single place (the msbuild script) and configure code inspection runner directly there rather than adding 20+ inspection build steps.
My understanding is that I can run "C:\TeamCity\buildAgent\plugins\dotnet-tools\bin\inspectcode.exe" manually from the script; with proper command line switches and config magic, I could achieve the same results as "Inspections (.NET)" build step has, with more control on the list of solutions to run the inspection on.
Is it a legitimate way of using the tool? Do you think there might be other issues I should be concerned about, such as high probability of breaking in the future?
Message was edited by: Sergii Volchkov
It is ok to run .net cmd tools (inspectCode.exe and dupFinder.exe) from build script. The only limitation is - you have to run it under TeamCity build agent. This fact is protected by TeamCity license agreement.
Still it is not a documented way of using .net cms tools. So we do not guarantee it will work in the future.
Also, I've created an issue for this case in our tracker. Please feel free to vote / watch / comment it.