MSBUILD : error MSB1008
At Antares, the development team has a standard process when applying updates to solutions which helps ensure our build and deployments of source code remains efficient. After performing such an update earlier this week, and once committing the source code to our code repository for safe keeping and project management needs, our continuous build process produced an unexpected error, MSBUILD: error MSB1008. Knowing that this build server and process has been fine tuned and working over a considerable period of time, it was a curious error indeed and critical to our workflow. This entry helps describe the issue and a potential fix to the immediate problem as found within Microsoft Visual Team Services (VSTS), specifically when using dotnet build templates.
TLDR;
problem: VSTS build process experiences an error in the console log describing that only one project can be specified, Switch: trx
fix: update the build template and process by simply removing the manual command switch as found within the arguments: –logger:trx
The Tell All…
After receiving the described error while performing an automatic build and deployment task in VSTS, reviewing the build logs to learn what the error was and why it occurred was critical. After combing through the various events, the team discovered the strange command that failed as follows:
Clearly it seems that the switch for the logged test results was somehow duplicated (note the two switches –logger:trx –logger trx found within the command). After reviewing the tasks in the build definition, it was discovered that the dotnet build template in use was updated to a newer version that fixed a previously reported issue with running XUNIT tests. Before, we had to manually indicate that we were using the XUNIT testing process, inject the type of results needed, and manually publish the results to our server environments for reporting purposes, all by using an argument:
--configuration $(BuildConfiguration) --logger:trxApparently, the new update to VSTS corrected this issue and now handles it natively. So because we had a manual switch and manual task handling this action, duplicate results were being specified and thus throwing an error message (not that the message helped trap this down with the exception of the Switch: trx). Therefore, modifying the argument by removing the logger switch and ensuring that the ‘Publish test results’ option is checked we are in good shape to restart our build processes.
The new build template and tasks for this particular build process looks similar to this:
Note that we disabled the manual ‘Publish Task’ instead of deleting it, just in case we need to add this back at some point.