FxCop in MSBuild and disabling CA0060 exceptions - msbuild

I am very new to MSBuild and it is taking me a little while to work out how to do things.
So I am trying to integrate FxCop into my project to be automatically run when I build them on the build server.
At the moment the way to go seems to be to add a custom task to the build that you call when you build. So I have so far created the following:
<Target Name="ExecuteFxCop">
<ItemGroup>
<Files Include="bin\XXXX.dll" />
</ItemGroup>
<!-- Call the task using a collection of files and all default rules -->
<MSBuild.ExtensionPack.CodeQuality.FxCop
TaskAction="Analyse"
Files="#(Files)"
SearchGac="True"
OutputFile="FxCopReport.xml">
</MSBuild.ExtensionPack.CodeQuality.FxCop>
</Target>
However when I run this >msbuild XXXX.csproj /t:ExecuteFxCop it fails with error 512 which I have narrowed down to an exception from indirectly-referenced assemblys:
<Exception Keyword="CA0060" Kind="Engine" TreatAsWarning="True">
<Type>Microsoft.FxCop.Sdk.FxCopException</Type>
<ExceptionMessage>The indirectly-referenced Silverlight assembly 'System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. Silverlight reference assemblies should be specified with the '/reference' switch. This assembly was referenced by: XXX\bin\ESRI.ArcGIS.Client.dll.</ExceptionMessage>
</Exception>
But I cannot add this reference. Is there a way to get the build to see this reference or preferably just disable the error altogether?
I did try: http://social.msdn.microsoft.com/Forums/en-US/vstscode/thread/c6780439-bc04-459e-80c3-d1712b2f5456/ but it doesn't work

Try the work-around here: http://geekswithblogs.net/blachniet/archive/2011/07/12/avoiding-fxcop-warning-ca0060.aspx
Edit
For example, using the FxCop MsBuild task, set ContinueOnError and check the ExitCode as follows:
<Target Name="ExecuteFxCop">
<ItemGroup>
<Files Include="bin\XXXX.dll" />
</ItemGroup>
<!-- Call the task using a collection of files and all default rules -->
<MSBuild.ExtensionPack.CodeQuality.FxCop
TaskAction="Analyse"
Files="#(Files)"
SearchGac="True"
OutputFile="FxCopReport.xml"
ContinueOnError="WarnAndContinue">
<Output TaskParameter="ExitCode" PropertyName="ExitCode"/>
</MSBuild.ExtensionPack.CodeQuality.FxCop>
<Error Condition="$(ExitCode) != 512" Text="FxCop failed with exit code: $(ExitCode)"/>
</Target>
P.S. (This is not tested)

Not sure if you're still looking for a solution but what usually works for me is adding the
fxcop cmd-option /d:{dir-of-random-assemblies}
which essentially tells fxcop to look in that additional directory for assemblies.
Adding a reference to a proj that doesn't need it is a bad idea in my opinion.
http://msdn.microsoft.com/en-US/library/bb429449(v=vs.80).aspx

Related

Passing dynamic references to Sandcastle Help File Builder

I've been using Sandcastle Help File Builder for a while to generate documentation - I'm now trying to get it to be part of our build process. Our build is controlled using NAnt, and each time it's built the output gets sent to a different location (based on changeset numbers, so we can have concurrent builds without clashes) - ie the dlls are not in a fixed path relative to the source code.
I've added a target into the NAnt script to call SHFB, which invokes the msbuild task, pointing at the solution that contains the SHFB project:
<target name="GenerateDocumentation">
<msbuild
project="${SourceURL}\Documentation\API Documentation\APIs.sln"
verbosity="Detailed">
<property name="OutputPath" value="${OutputPath}Documentation" />
<property name="ReferencePath" value="${OutputPath}wwwroot\\bin\\" />
</msbuild>
</target>
I've specified the ReferencePath property, as on this page, it seems to indicate that this would allow SHFB to find the assemblies and use them, rather than relying on the information in the original project file:
If the ReferencePath property is defined, it will be passed to and used by GenerateRefInfo.proj when generating reflection information. This allows you to specify an alternate path in which to find reference assemblies that will override hint paths in the project file.
However when the build reaches this point, it fails with the following error:
SHFB: Error BE0040: Project assembly does not exist: D:\Build\Debug\wwwroot\bin\MyAssembly.dll
Which is the default output path specified in the original project.
What is the correct mechanism for passing the location of the assemblies into SHFB?
Turns out that using OutDir instead of ReferencePath is the way to go:
<target name="GenerateDocumentation">
<msbuild
project="${SourceURL}\Documentation\API Documentation\APIs.sln"
verbosity="Detailed">
<property name="OutputPath" value="${OutputPath}Documentation" />
<property name="OutDir" value="${OutputPath}wwwroot\bin\\" />
</msbuild>
</target>
Also note that the path specified in OutDir must end in a double slash, otherwise MSBuild attempts to concatenate it with the project path

error MSB4064: The "OverwriteReadOnlyFiles" parameter is not supported by the "Copy" task

I am using Msbuild 4.0. When i was using Msbuild 3.5 OverwriteReadonlyfiles worked without any issue.
But today when i was trying to use the copy task i am getting this issue.
error MSB4064:
The "OverwriteReadOnlyFiles" parameter is not supported
by the "Copy" t ask. Verify the parameter exists on the task, and it
is a settable public instance property.
This is my target which has copy task
<Target Name="CopyBOM">
<Copy SourceFiles="#(BOM)" DestinationFolder="%(BOM.Destination)" OverwriteReadOnlyFiles="true">
<Output TaskParameter="CopiedFiles" ItemName="CopyBOMFiles" />
</Copy>
<Message Text="Copied to BOM: #(CopyBOMFiles)"/>
</Target>
Following is the itemgroup i am using in my properties file
<BOM Include="..\..\..\Release\CoreDeployment.msi">
<Destination>..\..\..\Core\BOM\Comp1</Destination>
</BOM>
I am having multiple properties file, I have verified that in all the place Toolsversion=4.0 is placed.
Has any one faced this? Any way is there to solve this?
I'm using OverwriteReadOnlyFiles="true" without issues. Try to add ToolsVersion="4.0" into your Project tag:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
You are most likely dealing with a ToolsVersion issue, even though you say you've checked all your files and their imports. Omitting the ToolsVersion from a file will cause it to drop to a lower version, so if all you did was search for "ToolsVersion" you may have missed a file where it wasn't declared on the <Project> node at all.
Run a command line build with diagnostic level logging, with the following additional parameters:
> msbuild My.proj /fl /flp:v=diag;logfile=My.proj.diagnostic.log
After the build fails, open the log file, seach for "MSB4064" then backtrack up the file looking for anything specifying the 2.0 framework.

Specifying assembly version of all projects within a web deployment wdproj script

I have a .wdproj Web Deployment Project created with VS2010 that contains references to other class libraries, like this:
<Project ToolsVersion="4.0" DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ProjectReference Include="..\Path\Proj1.csproj">
<Project>{GUID-HERE}</Project>
<Name>Proj1</Name>
</ProjectReference>
<ProjectReference Include="..\Path\Proj2.csproj">
<Project>{GUID-HERE}</Project>
<Name>Proj2</Name>
</ProjectReference>
There are lots of these. I want to be able to run msbuild /t:Rebuild /p:Configuration=Release and have all the assemblies of all the included projects compiled at a specified version. Nothing fancy just static like 2.5.6.0 and specified once in the wdproj file. I dont want to open 30 files manually.
I have looked at MSBuild Community Task and MSBuildExtension Pack and can not get anything to work. The build runs ok without errors.
Anyone have an example of how this can be done?
This is an attempt with MSBuild Extensions (adapted from the sample included) that doesn't work:
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.VersionNumber.targets"/>
<Target Name="Build">
<MSBuild.ExtensionPack.Framework.AssemblyInfo
ComVisible="true"
AssemblyInfoFiles="VersionInfo.cs"
AssemblyFileMajorVersion="2"
AssemblyFileMinorVersion="5"
AssemblyFileBuildNumber="6"
AssemblyFileRevision="0"
/>
</Target>
MSBuild is definately looking at the MSBuild.ExtensionPack.Framework.AssemblyInfo element because if the attribute names are incorrect the build will fail. This builds ok but none of the versions on the referenced assemblies are changed. The version numbers on the ASP.NET page assemblies from the website are all 0.0.0.0.
Are you maybe missing to specify the CodeLanguage and OutputFile attributes?
I think the AssemblyInfo task is intended to generate (replace) a source file prior to compiling.

What could cause the Wmi custom MSBuild task to throw "ManagementException not found"?

The Wmi task is part of the MSBuild Extension Pack. On one of our development machines, it thrown ManagementException not found. Here's the target:
<Target Name="Clean">
<ItemGroup>
<WmiProps Include="State"/>
<WmiProps Include="DisplayName"/>
</ItemGroup>
<!-- Create list of services that are currently running. -->
<Wmi TaskAction="Query" Class="Win32_Service WHERE DisplayName LIKE '%ServiceName%'" Properties="#(WmiProps)" Namespace="\root\CIMV2" MachineName="$(LocalDbServer)">
<Output TaskParameter="Info" ItemName="Info"/>
</Wmi>
<Wmi TaskAction="Execute" Class="Win32_Service" Method="StopService" Instance="Name='%(Info.DisplayName)'" Namespace="\root\CIMV2">
<Output TaskParameter="ReturnValue" PropertyName="Rval1"/>
</Wmi>
</Target>
The second WMI task is the one that throws the exception.
The error is pretty straightforward (the class wasn't found). I believe it's happening because you're attempting to query for a service by it's display name, not it's actual name. Switching the second task to be
Instance="Name='%(Info.Name)'"
Should probably do the trick.
Hope this helps,

Conditional compilation with automated builds in Visual Studio

Here's what I'm trying to do:
A single build script
That script builds two executables from the same Visual Studio project.
The first compiled .exe has a small amount of code disabled.
The other compiled .exe has everything enabled.
I've been reading up on conditional compilation and that takes care of my needs as far as enabling/disabling blocks of code.
I just can't figure out how to control conditional compilation from a build script using msbuild.
Is there a way to manipulate conditional compilation variables from a build script or some other way to accomplish what I'm trying to do?
Use build configurations in your project file. Set the parameters in a PropertyGroup that is optionally included based on the configuration. The configuration can then also define the output path for the two different versions of the assembly.
For the version that needs to remove some code use a configuration that includes the PropertyGroup.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'CompiledOutDebug|AnyCPU' ">
<DefineConstants>$(DefineConstants);MY_CONDITIONAL_COMPILATION_CONSTANT</DefineConstants>
</PropertyGroup>
Then use an MSBuild script that calls the project MSBuild script twice and uses the Properties attribute of the MSBuild task to specify the configuration to build:
<Target Name="Build">
<MSBuild Projects="MyProject.csproj;"
Targets="Build"
Properties="Configuration=Release" />
<MSBuild Projects="MyProject.csproj"
Targets="Build"
Properties="Configuration=CompiledOutDebug" />
</Target>
Hamish beat me to it.
Here's an alternate solution using the same concepts:
At the command line:
msbuild -t:Clean
msbuild
CopyOutputDirForWithoutDefine.cmd
msbuild -t:Clean
msbuild -property:DefineConstants=MY_CONDITIONAL_COMPILE_CONSTANT
CopyOutputDirForWithDefine.cmd
The 1st and 3rd 'msbuild -t:Clean' ensures that you don't have left over turds from previous builds. The 2nd 'msbuild' builds without the conditional define, while the 4rth builds with the conditional define.
If the above are just a couple on shot items, then a batch file maybe enough. I recommend learning a bit of MSBuild and actually scripting everything in a MSBuild file as Hamish has done.
If you don't want to create a separate target for the two compilations, you can do it by specifying the conditional define in the DefineConstants property when you call the build the second time:
<Target Name="Build">
<MSBuild Projects="MyProject.csproj;"
Targets="Build"
Properties="Configuration=Debug" />
<MSBuild Projects="MyProject.csproj"
Targets="Build"
Properties="Configuration=Debug;
AssemblyName=$(AssemblyName)_Conditional;
DefineConstants=$(DefineConstants);CONDITIONAL_DEFINE" />
</Target>
Note that if you do it this way, you need to also overwrite the AssemblyName, otherwise your second build might pick intermediate files from the first build.
You should also look at the MSBuild task docs on MSDN, there are some interesting tidbits there.