CleanupCode Command-Line Tool
CleanupCode is a free cross-platform command-line tool that can perform code cleanup (fix formatting, apply syntax styles, remove redundancies, and more) in a project or solution to ensure a uniform code base.
It can also reformat the specified set of .NET source files even without solution or project.
Download ReSharper Command Line Tools. Use the selector next to the Download button to choose your operating system.
Unzip the command line tools package in any directory.
Make sure that the downloaded .zip file is 'unblocked' before extracting: right-click the file, select Properties and click Unblock. Failure to do this will cause the .NET framework to load the application in partial trust, which means it won't load or run correctly.
If you are going to clean up a solution and use the solution file as an argument, make sure that the solution is built using the proper build configuration before running the tool.
warning
This step is very important. Without build, CleanupCode will not be able to resolve binary references, so it may fail to clean up parts of the solution's code.
Run the following command:
cleanupcode.exe YourSolution.slnto clean up an entire solution, or
cleanupcode.exe File1 File2 File3 ...to clean up one or more .NET files, or
cleanupcode.exe <FileMaskForTargetFiles>to clean up a set of .NET files that match the file mask.
Alternatively, you can install ReSharper command line tools as .NET tools and run CleanupCode with the
jbcommand.
tip
If you have problems running CleanupCode, make sure that your setup meets the system requirements.
tip
You can also run code inspection, and coverage analysis from the command line.
tip
If your project is under Git VCS, use
git diffafter running CleanupCode to reveal any changes that were made by the tool.
If you have previously worked on the target solution with ReSharper, you may have already configured code style settings. If so, CleanupCode will find your custom settings in .DotSettings files and apply them.
CleanupCode will read the following preferences from DotSettings files:
Code formatting rules (ReSharper | Options | Code Editing | General Formatting Style and ReSharper | Options | Code Editing | [Language] | Formatting Style)
Syntax styles (ReSharper | Options | Code Editing | [language] | Syntax Style)
File header style in C# and C++ (ReSharper | Options | Code Editing | File Header Text)
File and type layout in C# (ReSharper | Options | Code Editing | C# | File Layout)
Target languages (ReSharper | Options | Environment | Products — Features)
If you want to configure CleanupCode on a CI server, you can make all configurations locally with ReSharper, save the settings to the Solution Team-Shared layer, and then commit the resulting YourSolution.sln.DotSettings file in the solution directory to your VCS. CleanupCode on the server will find and apply these settings.
As an alternative, you can specify a path to a shared .DotSettings file (which will override settings in other settings files, if any) through the --settings parameter.
You can also configure code style settings via in EditorConfig for all languages and Clang-Format for C++, JavaScript, and TypeScript . These settings can be stored in .editorconfig, .clang-format, or _clang-format files on different levels of your solution hierarchy. The files are normally put under VCS so that settings defined there are shared among the project team.
ReSharper lets you use EditorConfig to define any of its code style preferences that are available in the ReSharper's Options dialog. You can find names and descriptions of supported EditorConfig properties in the EditorConfig reference.
As for Clang-Format, ReSharper will only apply the supported Clang-Format options.
It is important to note that any code style property defined in an .editorconfig file will override the same property defined in ReSharper settings in the scope where this .editorconfig file applies. Formatting properties defined in Clang-Format will override both ReSharper settings and EditorConfig settings.
--profile— a code cleanup profile that lists cleanup tasks to execute.By default, CleanupCode will apply code cleanup tasks specified in the Built-in: Full Cleanup profile, that is all available cleanup tasks except updating file header.
There are two more built-in profiles — Built-in: Reformat Code, which only applies code formatting preferences and Built-in: Reformat & Apply Syntax Style, which applies code formatting preferences and code syntax styles.
To use one of these profiles or any custom profile, pass the profile name via the
--profileparameter, for example:--profile="Built-in: Reformat Code" YourSolution.sln.--include/--exclude— file masks that define which files to include/exclude during the cleanup. If both--includeand--excludeare defined and cover the same set of files,--excludewill have higher priority.You can use Ant-style wildcards in file masks:
?to match a single character excluding directory separators*to match zero or more characters excluding directory separators**to match any number of characters including directory separators/or\to match directory separators regardless of the OS path format
For example a pattern
**Test?\**.*will match the following files:C:
\Projects \MyTestX \data \file_one.txt /home /projects /TestY /file_two.xml
But not:
C:
\Projects \Test \data \file_one.txt /home /projects /TestY /file_two
To specify multiple paths or wildcards, separate them with the semicolon
;or use the--include/--excludeparameters multiple times.note
Excluding parts of the solution will not have any noticeable performance impact because ReSharper will still have to analyze all files. It will make the specified exclusions only at the last stage.
--properties— lets you override MSBuild properties. You can set each property separately (--properties:prop1=val1--properties:prop2=val2), or use a semicolon to separate multiple properties--properties:prop1=val1;prop2=val2.Note that the semicolon cannot be used inside values, for example:
--properties:ReferencePath="r:\reference1\;r:\reference2\". In such cases, add each value separately using another--propertiesparameter — the values will be combined.The specified properties are applied to all analyzed projects. Currently, there is no direct way to set a property to a specific project only. The workaround is to create a custom property in this project and assign it to the desired property, then use the custom property in CleanupCode parameters.
--toolset— use this option to specify the exact MSBuild version. For example 12.0:--toolset=12.0By default the highest available MSBuild version is used. This option might not work if you have several installations with the same version, for example 16.0 from Visual Studio 2019 and 16.0 from .NET Core 3.x.--toolset-path— use this option to specify the exact path to MSBuild. This might be helpful if you have a custom MSBuild installation and want to use it with CleanupCode, for example:--toolset-path="c:\tools\msbuild\bin\MsBuild.exe".--dotnetcore— by default, .NET installation is auto-detected. You can use this option to point to the specific .NET installation if the auto-detection results in a conflict. Use it without arguments to ignore .NET Core. Example:--dotnetcore=/usr/local/share/dotnet/dotnet.--dotnetcoresdk— use this option to specify .NET SDK version that should provide MSBuild. For example, if you have installed .NET with SDKs 5.0.100 and 6.0.302, CleanupCode will prefer 6.0.302 (the latest, including preview versions). Now if you want to run CleanupCode with .NET SDK 5.0.100, add--dotnetcoresdk=5.0.100to the command line.--mono— by default, Mono installation is auto-detected. You can use this option to point to the specific Mono installation if the auto-detection results in a conflict. Use it without arguments to ignore Mono. Example:--mono=/Library/Frameworks/Mono.framework/Versions/Current/bin/mono.--targets-for-references— Names of custom MSBuild targets that will be executed to get referenced assemblies of projects. The targets are defined either in the project file or in the .targets file. Multiple values are separated with the semicolon. For example,--targets-for-references="GetReferences".--targets-for-items— Names of custom MSBuild targets that will be executed to get other items (for example, a Compile item) of projects. The targets are defined either in the project file or in the .targets file. Multiple values are separated with the semicolon. For example,--targets-for-items="GetCompileItems".
--verbosity— by default, CleanupCode only displays error messages in the output. Use this parameter to change the amount of information written to the output by the following levels (the order is from less to more detailed):[OFF, FATAL, ERROR, WARN, INFO, VERBOSE, TRACE].--LogLevel— use this parameter to control the amount of information written to the log file, specified via--LogFileor--LogFolder. There are following levels (the order is from less to more detailed):[OFF, FATAL, ERROR, WARN, INFO, VERBOSE, TRACE].For example, if something goes wrong with CleanupCode, you can contact ReSharper support and share a log file with all TRACE messages:
--LogLevel=TRACE.--LogFile— use this parameter to specify an absolute path to the log file for messages from CleanupCode. If you also need logs from MSBuild and Roslyn, use the--LogFolderparameter instead.--LogFolder— use this parameter to specify an absolute path to a directory where logs from CleanupCode as well as logs from MSBuild and Roslyn should be written. If you only need logs from CleanupCode, use the--LogFileparameter instead.--caches-home— lets you specify a custom location for the data that CleanupCode caches. By default, the %LOCALAPPDATA% directory is used, unless there are settings files, in which case the one specified there is used. This parameter can be helpful if you want to use a fast SSD disk for the cache or if you want to store all your build processing data in a single place.--config-createand--config— these options allow you to pass the parameters described above with a configuration file. The first option will create a configuration file according to the current parameters; the second option is used to load the parameters from this file.--debug (-d)— use this option to add execution details of CleanupCode to the output. If you have problems with CleanupCode, these details will be helpful when contacting the support team.--eXtensions (-x)— installs and enables the specified plugin.Plugins are specified by their IDs, which you can find on the plugin's page of JetBrains Marketplace: select .NET Tools, find the desired plugin, click Versions and then click the latest version.
For example, the plugin ID of the StyleCop by JetBrains plugin is
StyleCop.StyleCopand to run CleanupCode with this plugin, you need to add-x=StyleCop.StyleCopto the command line.To specify multiple plugins, separate their IDs with the semicolon.
--source— lets you specify a custom package source to install the plugin from, that is a directory where the .nupkg file with the plugin is located, for example,--source="C:\plugins". If nothing is specified, CleanupCode will look for plugins in JetBrains Marketplace.--measure— a diagnostic option that can help you if you experience suboptimal performance when running the tool on specific hardware with a specific target solution. Use this option with one of the following arguments[sampling | timeline (Windows-only) | memory]to define the kind of profiling, for example:CleanupCode.exe YourSolution.sln --measure=timelineWhen the execution is finished, CleanupCode creates an execution snapshot and displays the path to the snapshot file. You can study the snapshot using JetBrains tools:
Sampling or Timeline profiling: to analyze the resulting .zip file, unzip it and open the sampling snapshot files (.dtp) or timeline snapshot files (.dtt) with JetBrains dotTrace.
Memory profiling: to analyze the resulting dotMemory workspace file (.dmw), open it with JetBrains dotMemory.
--version (-v)— use this option to display the current version of the tool and exit.
--settings— by default, CleanupCode will override its default settings with ReSharper settings from the 'Solution team-shared' layer SolutionName.DotSettings, if it exists. If necessary, you can use this parameter to specify another .DotSettings file, which will override all other settings. For example,--settings="C:\Work\MyRsSettings.DotSettings".
--disable-settings-layers (-dsl)— disables specified settings layers. Accepted values:GlobalAll,GlobalPerProduct,SolutionShared,SolutionPersonal--no-buildin-settings— suppresses settings from global, solution, and project setting layers. Equivalent to--disable-settings-layers: GlobalAll; GlobalPerProduct; SolutionShared; SolutionPersonal; ProjectShared; ProjectPersonal
When CleanupCode receives the target solution file, it needs to create a list of files to be cleaned up and initialize a number of properties, such as language version. CleanupCode uses MSBuild to get this information from project files.
In most cases, CleanupCode automatically finds the proper MSBuild executable for the target solution. But there might be problems that prevent auto-detection, such as when the version of the solution runtime does not match the version of the installed .NET SDK.
If CleanupCode yields an error such as The current .NET SDK does not support targeting .NET Core 3.0. or The SDK 'Microsoft.NET.Sdk' specified could not be found., you need to specify the correct SDK or runtime using additional parameters. If you work with .NET, MSBuild is already installed on your machine, and often more than one installation exists, so you have to provide one that fits the target solution.
In most cases you will have to add just one parameter — --toolset or --dotnetcore. In complicated cases, for example, many different installations on the machine or when using a custom version of MSBuild, you may need other parameters: --toolset-path, --mono, --targets-for-references, --targets-for-items.
When you specify --dotnetcore or --dotnetcoresdk, CleanupCode will try to use MSBuild from .NET SDK and ignore others. For example, if you have several installations of MSBuild v 16.0 on your machine and specify a path to .NET installation with --dotnetcore, CleanupCode will use .NET MSBuild from the specified installation. When --dotnetcore is not specified, CleanupCode will look into the solution directory, try to find global.json, and use the SDK version specified there. If nothing is found, the latest available SDK version will be used.
MSBuild is also used by CleanupCode to resolve symbols from referenced projects and assemblies. There are two project properties that allow using different references depending on the environment: Platform and Configuration. If the environment where you run CleanupCode differs from the environment where the project was last built, you can receive errors such as: Can't resolve reference XXX: Reference wasn't resolved by MsBuild or Could not resolve this reference. Could not locate the assembly "XXX".
If you get such an error, check the output to see whether there is a mismatch in build configurations. For example
.....
JetBrains Inspect Code 2020.1
Running in 64-bit mode, .NET runtime 4.0.30319.42000 under Microsoft Windows NT 10.0.17134.0
Custom settings layer is mounted. Used file XXXXX.DotSettings
Using toolset version 15.0 from "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin"
Configuration: Debug, Platform: x86
.....In the above, you can see that the platform specified in the project file is x86, but the tool is running in a 64-bit mode. To fix this, specify the target platform and the configuration explicitly with the --properties parameter: --properties:Platform=x64;Configuration=Debug.
CleanupCode supports the following languages:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
| | | | |
warning
The active development of code cleanup features for JavaScript, TypeScript, and CSS is suspended, and code cleanup is not performed in these languages by default. If you want CleanupCode to work with these languages, you can enable their support using DotSettings.