AltCode.Dixon 2022.1.8.13182

There is a newer version of this package available.
See the version list below for details.
dotnet add package AltCode.Dixon --version 2022.1.8.13182                
NuGet\Install-Package AltCode.Dixon -Version 2022.1.8.13182                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="AltCode.Dixon" Version="2022.1.8.13182" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add AltCode.Dixon --version 2022.1.8.13182                
#r "nuget: AltCode.Dixon, 2022.1.8.13182"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install AltCode.Dixon as a Cake Addin
#addin nuget:?package=AltCode.Dixon&version=2022.1.8.13182

// Install AltCode.Dixon as a Cake Tool
#tool nuget:?package=AltCode.Dixon&version=2022.1.8.13182                

altcode.dixon

FxCop v17 (Visual Studio 2022) rule extensions and related code. A project named for that well known police constable of yesteryear. Intended for use with F#, since we don't have Roslyn analyzers there.

Features

FxCop for netstandard2.0

An executable, DixonCmd.exe that injects a netstandard2.0 compatible platform definition into the FxCopCmd process and launches an analysis session.

FxCop extra rules

Never mind the fluff -- How do I use this?

The package contains a subfolder tools which contains everything, including a further subfolder Rules containing just the rules assembly.

  • Copy FxCop from under Visual Studio to some (.gitignored as required) location within your project.
  • Copy the Dixon NuGet package tools folder into the same directory as above (or just the Rules subfolder into the Rules subfolder if netstandard2.0 support isn't relevant; or omit the Rules subfolder if those are not wanted)
  • Copy the FxCopCmd.exe.config to DixonCmd.exe.config if netstandard2.0 support is desired.
  • You may need to copy the FSharp.Core.dll assembly from tools anyway if you're not an a machine with F# development -- do this if there's an obvious failure to load because it's not there.

Now for framework assemblies use FxCopCmd.exe as before from the new location, where it will pick up the Dixon rules. For netstandard2.0 assemblies, use DixonCmd.exe /platform=<path to DotNet sdk ref subfolder containing netstandard2.0.dll> e.g. DixonCmd.exe "/plat:C:\Program Files\dotnet\sdk\6.0.101\ref"

Finding the Dixon parts

I've used a dummy .csproj to install tooling packages that aren't dotnet tool items (things like unit test console runners for .net Framework, or PowerShell modules such as Pester) to a non-cache location using dotnet restore --packages

Your build script can parse the .csproj as XML to find the version under the altcode.dixon folder

Finding the FxCop tool

It's at %ProgramFiles\Microsoft Visual Studio\2022\<edition>\Team Tools\Static Analysis Tools\FxCop or %ProgramFiles(x86)\Microsoft Visual Studio\2019\<edition>\Team Tools\Static Analysis Tools\FxCop; to automate the process in your build scripts, it's simplest to use the BlackFox.VsWhere package --

  • BlackFox.VsWhere.VsInstances.getAll() to get installed versions
  • select one of those with InstallationVersion property major version 16 or 17 as appropriate to your process
  • FxCop is in folder Team Tools/Static Analysis Tools/ beneath the InstallationPath property

Running the DixonCmd tool

As well as needing the path of the netstandard2.0.dll in the build environment, the process will need to be fed with the non-platform dependencies through the /d: command line argument e.g.

"/d:<nuget cache>/packages\<package name>/<package version>/lib/netstandard2.0"

Some dependency lacks will be obvious from the error messages, but some are subtle and need to be deduced from the exception details in the FxCop report file. In particular it may be necessary to add .net Framework 4.7.2 (or at least its reference asseblies to handle resolution failures with obvious platform functionality)

In greater detail

Here's the recipe I use, including appropriate sections of Fake.build scripting.

Developer/Contributor info

Build process from trunk as per appveyor.yml

Assumes VS2022 build environment

  • dotnet tool restore
  • dotnet fake run .\Build\setup.fsx
  • dotnet fake run .\Build\build.fsx

Direction

The F# focus will include making rule variants that are more F# aware, to separate out the compiler generated clutter from the code the developer can affect -- avoiding smothering the code in [<SuppressMessage>], or throwing rules out for poor signal to noise. But there will inevitably be some more originals.

Badges

  • Nuget
  • Build status
  • Build history
  • CI
  • Build history]
There are no supported framework assets in this package.

Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
2022.12.6.11014 1,026 12/6/2022
2022.1.8.13182 1,144 1/8/2022

## Never mind the fluff -- How do I use this?

[Here's the recipe I use](https://github.com/SteveGilham/altcode.dixon/wiki).

# 2022.1.8.131xx

* `DixonCmd` tool to extend FxCop support to netstandard2.0 (no other `dotnet` platform versions, at least not yet)

For previous releases, go here -- https://github.com/SteveGilham/altcode.dixon/blob/master/ReleaseNotes%20-%20Previously.md