1.4.19. Migration to 7.8.0¶
Caution
Default value of option
/Results/Dashboard/advanced.import_only_first_style_violation_per_line
has changed from true to false, meaning that from now on, identical
issues in the same line will be reported multiple times. This is now the preferred
behavior because it results in better consistency of the dashboard with exported
reports.
In the past (with old default true), issues have been only reported once per
line, if the only differentiating property of the issues was the column number.
Now (with new default false), issues will be reported multiple times per
line, once for each occurrence within the line.
This may result in an increase of issues for your existing projects.
If you want to keep the old behavior, then you have to manually configure the option
/Results/Dashboard/advanced.import_only_first_style_violation_per_line
in your project configuration back to true before running analyses with
version 7.8.0 onwards.
If you already ran an analysis on a project before setting the value back, please get in contact with us in order to remove the inadvertently done analyses from your project database.
Caution
cafesharp has been deprecated in favor of csharp2rfg, see below for
more information.
1.4.19.1. MSBuildIntegration¶
The support for C# in the MSBuild integration build action has been deprecated in favor
of the AxivionC#Frontend build action.
Compared to the MSBuild integration based on cafesharp AxivionC#Frontend offers
first-class support for MSBuild solutions, solution filters and project files, therefore
the configuration for AxivionC#Frontend is very different from
MSBuildIntegration / cafesharp. Depending on the size of your solution,
it may be easier to create a new configuration from scratch, however, you can follow
these steps in general:
Before you start, be sure to create a copy/backup of the existing configuration. Once you
have opened your configuration, disable the MSBuildIntegration build action
and Command build actions that invoke collect_projects.exe. Next, you
should add a new AxivionC#Frontend build action and move it the correct position
in the list (next to MSBuildIntegration). Configure the newly created
AxivionC#Frontend build action by migrating the options as follows:
Old option name ( |
New option name ( |
Notes |
|---|---|---|
|
|
Location of MSBuild.exe. If this option is not specified, this tool will try to auto-detect the MSBuild executable. |
|
|
This corresponds to the project/solution configuration setting. |
|
|
This corresponds to the project/solution platform setting. |
|
|
Note: The new option name uses the plural form. This is the list of MSBuild targets to be
executed during build. Default: |
|
|
This specifies the solution, solution filter, project, folder or source file to be analyzed. |
|
|
List of MSBuild properties to be used. This corresponds to the |
If you were previously analyzing a solution (and were using collect_projects.exe)
you can now directly use the solution in the solution option without any
intermediate steps.
If you want to exclude some projects from the analysis, you can do so by creating a
solution filter (.slnf) in Visual Studio and use it instead of the solution file.
See https://learn.microsoft.com/en-us/visualstudio/ide/filtered-solutions
for more information. Note that project types not supported by csharp2rfg
(such as .vbproj or .vcxproj) will be skipped in any case.
Target Framework Support¶
If you are analyzing a solution or project that targets different or multiple target
frameworks, the parameter build_target_framework must be configured to use the
target framework that matches the environment where the analyzed application is executed.
To find the correct target framework look for a TargetFrameworkVersion,
TargetFramework or TargetFrameworks XML attribute in your C# project files.
See https://learn.microsoft.com/en-us/dotnet/standard/frameworks for more information.
Migration of C# analysis rules¶
If you use any Stylecheck analysis outside of the C# rule group, you will have
to disable them and use the C#-specific counterpart in the C# rule group instead.
If there are any rules you want to use, which are not supported by AxivionC#Frontend
please get in touch.
If you are using the CloneDetection action in your project, you will have to enable
CSharpCloneDetection instead.
1.4.19.2. rm_branch_dbs¶
The tool rm_branch_dbs, which was introduced in release 7.2.3 and improved in
7.5.0, has been discontinued and its features have been integrated into the dashboard
itself. If you enable option Automatic Project Cleanup in the dashboard, then
projects where at least one registered VCS cannot be found anymore, are automatically
removed from the dashboard and eventually deleted from disk. This works for both,
shared_database projects as well as managed_upload.
This feature is currently only implemented for VCS Git by checking the existence of the branch on the remote, but it can be extended to other VCS in the future.
1.4.19.3. MicrosoftToolchain¶
The Microsoft toolchain now defaults to linking in also unused objects from libraries. This emulates more closely the behavior of the Microsoft linker link.exe at the cost of larger IR files and new analysis results of previously discarded objects from libraries.
If the new behavior is not desired, please set linker.include_unused=false to
revert back to the old behavior.
1.4.19.4. Dashboard Server and PluginARServer¶
Java 17 or later will be required for Axivion Suite 7.9 onwards.
Please be aware that these tools are required for the local analyses from the IDE plugins (Dashboard Server: local build, PluginARServer: single file analysis).
1.4.19.5. Dashboard Permissions¶
Note
Due to the changes mentioned in the two paragraphs below, the token type
Continuous Integration is now actually usable for CI use cases as implied by
its name. Most importantly it is now possible to do project
installation/deinstallation without the Configure Dashboard permission and we
thus highly recommend, you either remove the permission Configure Dashboard
and replace it with Update Artifacts for your existing General Purpose
token owners (this is possible without issuing a new token), or you revoke your
old General Purpose tokens used for CI use cases and issue new tokens of type
Continuous Integration.
Update Analysis Artifacts Permission¶
The permission Update Analysis Artifacts is now project specific, which means that an existing project namespace partitioning can be enforced also in the managed_upload use case. An automatic migration will convert existing grants of the old global permission to grants for *. We still recommend reviewing your dashboard’s permission configuration page after updating and also to potentially reduce the scope of existing grants of the Update Analysis Artifacts permission.
The same permission now has also been extended to allow for project installation and deinstallation via the official programming APIs.
Continuous Integration Token¶
Tokens of this type previously were very limited and only useful for some setups with managed_upload. This has now changed, and the Token Type is now usable for most CI use cases as implied by its name. The most notable additions are project installation/deinstallation (via Update Analysis Artifacts (Project)) as well as the usage of merge_issue_annotations.py (via View (Project), View Annotations (Project), Low-Level Issue Annotation Control (Project))
1.4.19.6. Dashserver Script¶
The –verbose switch has been removed and the output it produced is now controllable via the log level.
1.4.19.7. Dashboard Custom NamedFilter Keys¶
The format of keys for custom named filters has changed. This means, that if you have been hardcoding such a key somewhere, e.g. in a reporting script, you will need to update that reference.
1.4.19.8. Dashboard / VCS Configuration¶
For some VCS the dashboard needs to maintain its own repository clone in order to display source code (and offer deltas for Local Build analyses).
A change has been introduced that affects how the following options are interpreted:
Fossil/sourceserver_repository
Git/sourceserver_gitdir
Mercurial/sourceserver_hgdir
Shadow/sourceserver_repository(only for /Results/Dashboard/database_mode=shared_database projects)
Previously, the possibility of using a relative path as one of those options has been
undocumented, but worked, and the path was interpreted relative to the dashboard’s
config folder. Starting with release 7.8.0, this behavior slightly changes and
relative paths are now interpreted relative to the dashboard’s config/repositories
folder (which is created if it does not exist). If you already used relative paths for
those options, you should move those repository clones from config to
config/repositories manually once when upgrading to 7.8.0.
Using relative paths for those options is the recommended way of configuration now.
This change is done to be in line with a new feature that is opt-in: absolute paths
in the above-mentioned options can now be forced into this config/repositories
folder as well. This feature has to be enabled explicitly in dashboard2.config by
setting ForceRelativeRepositoryPath to true.
This helps in setups where the project configuration does not know internal folder structure layout on the dashboard server and may therefore create repository clones in undesired places due to misconfiguration.
Note, there is one exception to this behavior: If the configured absolute path already points to a location inside the parent folder of the dashboard configuration folder, it will not be changed, but taken directly to avoid cloning those repositories a second time.
Note also, that when switching ForceRelativeRepositoryPath to true and using
SpecialVCS Shadow in combination with
/Results/Dashboard/database_mode=shared_database,
you have to manually clone the shadow repository across your hosts. We recommend using
/Results/Dashboard/database_mode=managed_upload
instead if you need SpecialVCS Shadow and ForceRelativeRepositoryPath=true.
1.4.19.9. Legacy processline tools¶
The executable wrappers for the following tools have been removed: activate_members, activate_via_reflection_patterns, add_dynamic_variable_accesses, add_qt_connects, architecture_check, architecture_role_attributes, arxml_import, check_rfg_equality, compute_dependency_properties, copy_and_project, copy_view, create_dummy_memmap, create_types, cycles, dead_code, eaxmi11_to_rfg, graph_matcher, gravis_role_attributes, gxl_export, gxl_import, hierarchical_mapping, insert_system_node, obfuscate, remove_view, rfg_preparation, rpy2rfg, scripted_architecture, stack_depth, strip_basepath, taggedvalues_to_mapping, transitive_hull, uml_interpretation, view_projection, xaml_analysis, xaml_deadcode_analysis, xaml_to_rfg.
This change only impacts the convenience executable wrappers, for now the underlying tools remain supported in Rule Architecture-ProcessLine. However the whole processline is considered deprecated; we recommend switching to the corresponding Architecture-* rules. (e.g. activate_members -> Architecture-ActivateMembers)
1.4.19.10. Metrics¶
All RFG based metrics¶
RFG based metrics no longer report violations at namespace level by default.
The previous behavior can be restored by removing Namespace from the
excluded_node_types option for the desired metrics or groups.
Metric-CognitiveComplexity¶
The options report_per_routine, report_per_class and report_per_file were removed in favor of the existing metric propagation logic.
Additionally the unused option base_view_name was removed.
1.4.19.11. CloneDetection¶
Default configuration of the C/C++ clone detection changed in a way that aggregate
literals are no longer considered as potential clone candidates by themselves, because
most of the time they are not that interesting. If you want to revert back to the old
behavior, then you can do so by removing the IR class Aggregate_Literal from
the config option /Analysis/CloneDetection/advanced.exclude_classes in your
project configuration.
1.4.19.12. Stylechecks¶
FaultDetection rules and other rules based on StaticSemanticAnalysis¶
The options process_finding and process_all_findings were removed in favor of the existing post-processing framework.
There is no automatic migration, existing filters and post-processors have to be converted to the new API manually.
See the documentation of module axivion.analysis.post_processing in the analysis framework API reference.
CertC-ARR38, MisraC2012-21.18, MisraC2019-21.18, MisraC2023-21.18¶
These rules compare size arguments with the size of pointer targets and have been made more accurate by a buffer analysis. Previously, computed pointer sizes have been wrongly overestimated, because offsets into arrays or pointer additions have not been considered. This has lead to false negatives and wrongly computed sizes in messages.
The current settings of options avoid these false negatives but may lead to more false positives. As only one message is reported for each critical call it may happen that a message complaining about a possible size of zero (size_zero) will be replaced by the more critical message for the size being too large (size_too_large).
In order to restore the old behavior set option enable_buffer_analysis to false and
exclude_warnings_for_unknown_arguments to true. For CertC-ARR38 also the default
for the option use_type_based_maximum has been changed from false to true.
CWE-Random-Number-Issues-337 and CWE-Cryptographic-Issues-337¶
The option predictable_system_calls has been renamed to routines_returning_predictable_values.
Non-system routines are now accepted as well and can be provided using their fully qualified name.
MisraC2012-17.11¶
The option exclude_functions_without_definition was removed and functions
without definitions are now always excluded from this rule.
C#-CSharpReferencedLabelInSameBlockAsGoto¶
The rule C#-CSharpReferencedLabelInSameBlockAsGoto has been removed because
potential violations are already reported by the C# compiler using error CS0159.
This means that in practice this rule never produced any violations on valid C# code.
If the rule was enabled, it will be disabled and removed automatically.
1.4.19.13. IR scripting¶
node.Stable_Declaration property in the logical IR: In previous versions,
nodes lacking a declaration/definition returned the value of node.Physical as
their “stable declaration”. This fall-back code path has been removed to ensure that
the value returned by this property is always a declaration/definition.
If you have custom stylechecks/post-processing accessing the IR and are using
Stable_Declaration, replace x.Stable_Declaration with
(x.Stable_Declaration or x.Physical) to restore the previous behavior.
1.4.19.14. Gravis¶
Before 7.8.0, the actual Gravis executable was called gravis2
(gravis2.exe on Windows) and there was a wrapper available that allowed it to be
run as gravis, too. Starting from version 7.8.0 the main executable is now
called gravis (gravis.exe on Windows) and gravis2 is no longer
available. Any shell scripts or shortcuts launching Gravis as gravis2 have to be
adapted to run gravis instead.
The value of sys.executable for Python scripts running inside Gravis is now
gravis and no longer gravis2. Any scripts trying to detect whether they
are running inside Gravis by looking at sys.executable need to be adapted.
1.4.19.15. Test Driver perform_tests¶
The test driver perform_tests will from now on fail tests that produce duplicate outputs. This means that a test will fail if the tested rule reports the same violation more than once. If duplicate outputs are expected, they can be allowed by adding // allow_duplicate_messages: True to the test.
1.4.19.16. StaticSemanticAnalysis configuration¶
As part of our preparation for new analysis engines, we improved the configuration
structure for the rule StaticSemanticAnalysis.
Firstly, the rule is no longer a direct child of the Analysis/AnalysisControl rule
group, but has now a separate parent group called AnalysisEngine.
Secondly, we grouped the existing options into three distinct option groups:
debuggingfor options related to debugging and logging,
performancefor options that impact the runtime, memory consumption, and precision of the analysis engine, but do not remove valid findings (i.e., do not impact soundness), and
semanticsfor options that additionally impact the soundness of the analysis.
Consequently, the paths of all options have changed. In most scenarios, these changes do not require user action and will be migrated dynamically at runtime while the configuration is loaded. That run-time migration does not change any files. However, as soon as you make any changes to your configuration in the configuration GUI later it will be saved in its migrated state.
Manual interaction is required for these cases:
If you keep your Axivion configuration under version control and want to avoid unrelated diffs after future changes, you can manually migrate your configuration using the migration tool:
migrate config <your-config-file(s)>The migration tool will only migrate JSON files that contain options. For example, consider the following configuration directory:
❯ ls -al axivion/* -rw-r--r-- 1 user 197121 480 May 14 14:05 additional_rules.json -rw-r--r-- 1 user 197121 182 Nov 28 09:51 axivion_config.json -rw-r--r-- 1 user 197121 1436 May 13 15:20 ci_config.json -rw-r--r-- 1 user 197121 381 Nov 28 09:51 compiler_config.json -rw-r--r-- 1 user 197121 430 May 13 15:20 external_spec.json -rwxr-xr-x 1 user 197121 528 May 13 15:20 start_analysis.sh*Running the migration tool will only migrate the supported JSON files and report errors for other files:
❯ migrate config axivion/* axivion/axivion_config.json: Config contains _Layers, migration not supported. File axivion/start_analysis.sh is not supported. 1 files with return code SUCCESS: axivion/additional_rules.json 3 files with return code SUCCESS_NO_CHANGE: axivion/ci_config.json axivion/compiler_config.json axivion/external_spec.json 1 files with return code FAIL_UNSUPPORTED_FILE: axivion/start_analysis.sh 1 files with return code FAIL_CONFIG_HAS_LAYERS: axivion/axivion_config.json Stats: SUCCESS: 1 SUCCESS_NO_CHANGE: 3 FAIL_UNSUPPORTED_FILE: 1 FAIL_CONFIG_HAS_LAYERS: 1Further options are described by the output of
migration config --help.If you use JSON configuration files without
_VersionNumentry, the runtime migration will fail. In this case, usemigrate config --assume_version <your-version-before-updating> <your-config-file(s)>to perform a manual migration.
If you use a Python-based configuration where you configure
StaticSemanticAnalysisprogrammatically, you need to manually adjust the option paths.
The following table lists all changes.
Old path ( |
New path ( |
|---|---|
New option group |
|
|
|
|
|
|
|
|
|
New option group |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
New option group |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|