Routine MSBuild and CSC warnings - Resolve or suppress to ensure new substantive warnings are not overlooked

[softwarecraft]

There are several MSBuild and CSC warnings when compiling both projects which will make it hard to notice any new (eg substantive) warnings, eg when adding new features to the cmdlets. While it may seem easier to simply ignore these warnings, it would be helpful to resolve or suppress warnings that are expected, routine or of no consequence.

1) Two CSC warnings suggest small code changes are in order:

• warning CS0618: 'Microsoft.SharePoint.Administration.SPGlobalAdmin' is obsolete: 'Most of the functionality in this class is available in SPFarm or SPWebService.'
• warning CS0162: Unreachable code detected

Until the suggested code changes are made, these two warnings can be suppressed by adding /p:NoWarn="0618 0162" to the MSBuild command line in the script Build-WSPs.ps1 and/or by adding the warning numbers to the project Properties > Build > Errors and warnings > Suppress warnings setting.

Although /nowarn (C# Compiler Options) indicates to use a comma-separated list I wasn't able to do that in the context of the Build-WSPs.ps1 script even when using quotes and escaping the comma. Fortunately /nowarn also supports a space separated list.

2) An MSBuild warning can occur for the SharePoint 2013 project in the ResolveAssemblyReference task for the assembly Microsoft.SharePoint.Powershell if the v14 assembly is located before the v15 assembly, eg because of the AssemblyFoldersEx paths:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

And the log file details are:

There was a conflict between "Microsoft.SharePoint.PowerShell, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" and "Microsoft.SharePoint.PowerShell, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c". "Microsoft.SharePoint.PowerShell, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" was chosen because it was primary and "Microsoft.SharePoint.PowerShell, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" was not.

The root cause of this warning is because both projects include a reference to the Microsoft.SharePoint.Powershell assembly without fully qualifying it:

    <Reference Include="Microsoft.SharePoint.Powershell">
      <HintPath>ReferenceAssemblies\Microsoft.SharePoint.Powershell.dll</HintPath>
    </Reference>

whereas all the other SharePoint assembly references are fully qualified, eg for the SharePoint 2013 project:

    <Reference Include="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>ReferenceAssemblies\Microsoft.SharePoint.dll</HintPath>
    </Reference>

The solution is simple, update the project reference for the Microsoft.SharePoint.Powershell assembly to use a fully qualified reference, eg for the SharePoint 2013 project:

    <Reference Include="Microsoft.SharePoint.Powershell, Version=15.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>ReferenceAssemblies\Microsoft.SharePoint.Powershell.dll</HintPath>
   </Reference>

3) Two MSBuild warnings occur for the SharePoint 2010 project in the ResolveAssemblyReference task for the assemblies Microsoft.Office.Server.Search and Microsoft.SharePoint.Search, eg:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets (1697,5): warning MSB3270: There was a mismatch between the processor architect ure of the project being built "MSIL" and the processor architecture of the ref erence "Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, Publ icKeyToken=71e9bce111e9429c, processorArchitecture=MSIL", "AMD64". This mismatc h may cause runtime failures. Please consider changing the targeted processor a rchitecture of your project through the Configuration Manager so as to align th e processor architectures between your project and references, or take a depend ency on references with a processor architecture that matches the targeted proc essor architecture of your project. [C:\Projects\Repos\Lapointe\PowerShell-SPCm dlets\Lapointe.SharePoint2010.PowerShell\Lapointe.SharePoint2010.PowerShell.csp roj]

Because the project platform target is "Any CPU" whereas these two reference assembles are platform "x64" and MSBuild doesn't like this mismatch.

The solution may be to change the project platform target from "Any CPU" to "x64" but I'm somewhat fuzzy about the implications in this situation. Is there any scenario in which the Lapointe SharePoint PowerShell cmdlets could run in an x86 process space? Some bloggers advise in general to leave the platform target as "Any CPU" and let the runtime sort every thing out.

Also, making the switch to a platform target of "x64" results in a CSC warning on three assemblies, eg:

warning CS1607: Assembly generation -- Referenced assembly 'System.Data.d ll' targets a different processor [C:\Projects\Repos\Lapointe\PowerShell-SPCmdl ets\Lapointe.SharePoint2010.PowerShell\Lapointe.SharePoint2010.PowerShell.cspro j]

There is a good discussion on Stack regarding the resolution of this CSC warning, MSBUILD / csc: Cleanest way of handling x64 mscorlib warning 1607.

I would like further clarity on the solutions for both the MSBuild warning and the CSC warning before deciding for certain that they are worth it, but I would very much like to have a clean warning-free build.