I'm working on a MSBuild script that will retrieve all the sources from TFS and build all the Solutions. To my surprise one of my MSBuild scripts raised errors on a solution that was building fine in Visual Studio. In MSBuild I got the following error: "The type or namespace name "name" does not exist in the namespace "namespace". (Are you missing an assembly reference?)".
After a long hard search I found a stray projectreference in a project file (*.csproj). Usually all the References and Projectreferences are packed together in one ItemGroup, but in this specific project file there was one ProjectReference in a seperate ItemGroup at the end of the file. This was exactly the project that contained the namespace "name". I copied the ProjectReference to the ItemGroup containing all the other References and deleted the stray ItemGroup. This fixed the MSBuild errors.
Showing posts with label Team Foundation Server. Show all posts
Showing posts with label Team Foundation Server. Show all posts
Wednesday, August 4, 2010
Difference in MSBuild and Visual Studio Build?
Labels:
.NET,
MSBuild,
Team Foundation Server,
Visual Studio
Thursday, July 29, 2010
UnitTests and Code Coverage in TFS Build 2008
The last couple of days I've been working on getting code coverage results from unittests in automated TFS builds. Getting the code coverage results in Visual Studio 2008 is very straightforward:
Getting the Code Coverage Results in the Automated TFS Build is a bit tricky.
Open the TFSBuild file and add the following line in the PropertyGroup node: "<RunTest >true </RunTest>"
In the ItemGroup for UnitTesting add the following lines (if you have multiple unittest projects in your Build, add one for each unittest project)
<MetaDataFile Include="$(FolderPath)/TestListEditor.vsmdi" >
<TestList >NameOfTestListToRun </TestList >
<TestRunConfig >$(FolderPath)/LocalTestRun.testrunconfig </TestRunConfig >
</MetaDataFile >
After you run your build you should see that there are now UnitTest Results and Code Coverage Results in your Build Summary.
Unfortunately this wasn't the case in my project. I got a partially succeeded build, the building itself succeeded and all my unittest passed, but still I got a partially succeeded build. I noticed that the buildlog contained a lot of the following warnings: "Warning VSP2013: Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this." After some google searches I found this.
The article basically says that the buildserver makes 64 bit dll's and it can't place the instrumentation code for Code Coverage in these dll's because the Code Coverage runs as a 32 bit proces. Microsoft doesn't plan to fix this in the current release, but keep an eye out for new versions. After some more searching I found some other fixes for this problem, you can change the BuildConfiguration to always build Debug|x86 or you can do some Registry hacks on the buildserver. I didn't like any of these solutions so I started to look for different options.
The best option I could find was the following:
In the LocalTestRun.testrunconfig under Code Coverage there's an option to "Instrument assemblies in place" if you unselect this option the Code Coverage instrumention will be placed in a copy of the dll and not in the same dll. Unselect this option and restart the build.
You will now see that the build will complete succesfully!
- Double click on the LocalTestRun.testrunconfig
- Go to "Code Coverage"
- Select the artifacts to instrument (dll's)
- Enter the path to the resigning key file
- Click "Apply" and "Close"
Getting the Code Coverage Results in the Automated TFS Build is a bit tricky.
Open the TFSBuild file and add the following line in the PropertyGroup node: "
In the ItemGroup for UnitTesting add the following lines (if you have multiple unittest projects in your Build, add one for each unittest project)
<
<
After you run your build you should see that there are now UnitTest Results and Code Coverage Results in your Build Summary.
Unfortunately this wasn't the case in my project. I got a partially succeeded build, the building itself succeeded and all my unittest passed, but still I got a partially succeeded build. I noticed that the buildlog contained a lot of the following warnings: "Warning VSP2013: Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this." After some google searches I found this.
The article basically says that the buildserver makes 64 bit dll's and it can't place the instrumentation code for Code Coverage in these dll's because the Code Coverage runs as a 32 bit proces. Microsoft doesn't plan to fix this in the current release, but keep an eye out for new versions. After some more searching I found some other fixes for this problem, you can change the BuildConfiguration to always build Debug|x86 or you can do some Registry hacks on the buildserver. I didn't like any of these solutions so I started to look for different options.
The best option I could find was the following:
In the LocalTestRun.testrunconfig under Code Coverage there's an option to "Instrument assemblies in place" if you unselect this option the Code Coverage instrumention will be placed in a copy of the dll and not in the same dll. Unselect this option and restart the build.
You will now see that the build will complete succesfully!
Labels:
.NET,
Team Foundation Server,
UnitTesting,
Visual Studio
Subscribe to:
Posts (Atom)
