Build problem – Solved

Yesterday, I posted about a problem with MSBuild building our solution. We solved it, so I wanted to let you in on the secret solution.

We use the Enterprise Library V1.2 in some of our projects. And because some of the projects are being re-used from other internal projects, not all the references in thos projects were checked for versions. As it turned out, another project had a reference to an enterprise library assembly with a runtime version of .NET 2.0. And allthough this project compiled succesfully, local and on the build server, it broke the build of one of the other projects. This project (the one with the wrong reference) didn’t need the EntLib reference, so it ‘disappeared’ because of optimization. But reference resolving had resolved it, and pointed to EntLib 3.0. Later in the build the project which failed did need the EntLib file, and used the allready resolved assembly location.

The problem occured after EntLib 3.0 was installed on the build server. I think the problem is there because of  breaking changes between EntLib 2.0 and 3.0, because you would think the assembly resolver would have found the EntLib 2.0 assembly earlier. I’ll be checking for that on monday. And if I’ll find anything weird, I’ll get back at you.

By the way, we solved this problem by using the verbose mode of MSBuild. This mode logs everything very extensively. Because of this, we could see the assembly reference resolving process, which lead us to the problem. You can make MSBuild more verbose by locating your build’s rsp file, and add /v:diagnostic to it. However: use this option with care. It made our buildlog 200+ Mb’s for a 71 project solution.

• dotnet