CAST IMAGING – V3 – FAQ - Functional changes in Imaging V3 when compared with Imaging V2 – CAST

There are some architectural changes in Imaging V3 when compared with Imaging V2 which has resulted in few functional changes in V3.

Details

How is CAST Imaging V3 interface different from CAST Imaging V2?

V2 had separate interfaces for Console and Viewer; V3 consolidates these into Single UI for application onboarding, analysis setup, viewing, and configuration.

Does CAST Imaging V3 support the Legacy onboarding workflow?

No. The Legacy onboarding workflow has been completely removed in V3.

What onboarding workflow is available in CAST Imaging V3?

V3 supports only the Fast Scan onboarding workflow. It is now the sole method for onboarding applications.

How does application Scan in V3 differ from V2?

In V2, users could:

Use different onboarding workflows (including Legacy)
Restrict execution up to the DMT step
Set the current version
Customize the analysis unit before proceeding

In V3:

Only Fast Scan is available
Version management has been removed
The process operates exclusively in Fast Scan mode
There is no intermediate pause for customization during execution

Where is the application source code stored in Imaging V3?

In Imaging V3, the workflow has been redesigned so that uploaded source code is stored in a persistent upload directory instead of being deployed to the SourceDeploy folder.

Imaging V3:
Uploaded source code is stored under
<CommonData>\upload\
Imaging V2:
Source code is deployed and expanded into the configured SourceDeploy folder (for example D:\CAST\deploy).

As a result, the upload directory is now the primary persistent storage location for application source code in Imaging V3.

What is the role of the SourceDeploy folder in Imaging V3?

In Imaging V3, the SourceDeploy folder is no longer used for permanent source code storage. Instead, it is used primarily for dependency resolution artifacts and technical package extraction, such as:

Maven repository packages (mavenHttpPck)
.NET assemblies (assemblies-pkg)

The actual application source code is stored only in the upload directory.

How does Imaging V3 maintain incremental scan continuity when the physical source path changes?

Imaging V3 ensures incremental scan continuity through the force installation of the "KB portable root path" extension.

Is the Delivery Manager Tool (DMT) available in V3?

No. The Delivery Manager Tool (DMT), previously used in CAST AIP and Console workflows to:

Package and deliver source code
Manage imports
Interact with the analysis pipeline

is not available in V3.

Is CMS (CAST Management Studio ) available in V3?

CMS for configuration, source delivery tracking, project settings, etc is no longer supported in Imaging V3.

Can users restrict execution up to the DMT step in V3?

No. In V3, restricting execution up to the DMT step is no longer supported.

Is version management available in CAST Imaging V3?

No. Version management functionality has been removed in V3.

Can users customize the analysis unit before running analysis in V3?

No. Unlike V2, V3 does not provide an intermediate option to pause and customize the analysis before proceeding.

What are the steps in the Fast Scan workflow in V3, how it is different from V2?

The V3 workflow is divided into four steps:

New Scan
Deep Analysis
Compute Structural Flaws
Generate Views

In Imaging V3 after completing Fast Scan Configuration, the Analysis, Modules, and Dependencies tabs are disabled. In V2, it was possible to restrict the execution up to the DMT step, set the current version, customize the analysis unit, and then proceed with the analysis. In V3, version management is no longer present, and the process operates exclusively in FAST SCAN mode.

What happens during the Deep Analysis step in V3?

During the Deep Analysis step:

The schema is created
Extensions are installed
File exclusions (if any) are applied
The analysis is executed

Currently, there is no option to pause within this step to perform additional customizations before continuing.

Why are the Analysis, Modules, and Dependencies tabs disabled after completing Fast Scan Configuration in V3?

In V3, the process runs strictly in Fast Scan mode with a predefined workflow. As a result:

Manual version control is no longer available
Custom execution boundaries (such as stopping at DMT) are removed
The Analysis, Modules, and Dependencies tabs are disabled after Fast Scan configuration

Are Content Enrichment tools available in CAST Imaging V3?

No. Content Enrichment tools that were previously available through CMS (CAST Management Studio) are not supported in V3.

In V2, CMS was used for:

Configuration management
Source delivery tracking
Project settings
Executing custom enrichment processes

Since CMS is no longer supported in V3, these capabilities have been removed.

Can custom BAT scripts be executed in V3 to remove unwanted files or folders?

No. In V2, custom BAT scripts could be executed before or during analysis to remove unwanted files or folders. This functionality is not supported in V3.

Can post-snapshot SQL scripts be executed in V3?

No. In V2, it was possible to run post-snapshot SQL scripts to remove external JavaScript objects from the local schema. This is not supported in V3.

Is version management available in CAST Imaging V3?

No. Since DMT is not available in V3, version management functionality is also not available. In V2, version management was supported through AIP and Console workflows.

Are all technologies supported in V2 also supported in V3?

Not necessarily. V3 currently runs on Imaging Core 8.4, which may not yet support all technologies that were supported in V2 through AIP Core 8.3. Additional technology support is planned for future releases.

Can artifact counting logic be customized in Imaging V3?

No. There is currently no supported mechanism in V3 to redefine sizing measures (such as number of artifacts) the way it was possible in V2 via CMS. Sizing calculations follow the default logic defined by the platform.

In V2, using CAST Management Studio (CMS), users could customize sizing measures through:

CMS > Assessment Model > Sizing Model

This allowed modification of artifact counting logic used for sizing calculations.

Does the Sizing Model concept exist in Imaging V3?

No. The Sizing Model concept available in CMS does not exist in Imaging V3. V3 does not provide a configuration layer to redefine artifact counting rules

Is currency-based Technical Debt available in Imaging V3?

No.

In Imaging V3:

The legacy currency-based Technical Debt value is not displayed in the dashboard.
CMS-based currency configuration is no longer applicable.

How is currency-based Technical Debt calculated in Imaging V3?

Instead of custom currency parameters, CAST now recommends using the OMG Automated Technical Debt Measurement (ATDM) standard.This is implemented through the official extension:

OMG Automated Technical Debt (ATDM) Extension Extension ID: com.castsoftware.omg-atdm
This extension aligns Technical Debt calculations with the OMG standard model rather than user-defined monetary parameters.

Extension can be download from CAST Extend
https://extend.castsoftware.com/#/extension?id=com.castsoftware.omg-atdm&version=2.0.4-funcrel

How is Security Dataflow handled differently in V3?

In V2:

Security Dataflow was disabled by default
It had to be manually enabled

In V3:

Security Dataflow is enabled automatically by default
Applies to supported technology stacks (e.g., JEE, .NET) during initial analysis

Does V3 support all technologies that V2 supported?

Not necessarily.

V3 currently runs on Imaging Core 8.4, which may not support all technologies that were supported in V2 via AIP Core 8.3.

Additional support is planned for future releases.

How does the Standalone Dashboard in V2 compare to dashboard functionality in V3?

In V2, CAST provided a separately deployable Standalone Dashboard component. It:

Ran independently from Console and Viewer
Had its own URL and required a separate web server deployment
Required separate installation and configuration
Provided Engineering, Health, Security, and Management metrics
Enabled portfolio-level reporting
Allowed executive or management users to access dashboards without full Console access
Required users to switch between multiple interfaces (Console, Viewer, Dashboard)

In V3, there is no new standalone dashboard component. Instead:

Dashboard functionality is fully integrated into the unified Imaging V3 interface
No separate deployment or dedicated server is required
No separate dashboard URL is needed
Access is centralized within the single platform UI
The architecture is simplified from a multi-component model to a unified platform model

Migration Note:

Existing V2 standalone dashboards can continue to function after migration because they rely on analysis result schemas that remain accessible. However, they are considered legacy components and are not part of the new V3 architecture. No new standalone dashboard capability is introduced in V3.

What is the CARL engine analyzer in Imaging V3, Is it present in V2?

The CARL engine is the analysis runtime engine responsible for executing code analysis in Imaging V3.

Its responsibilities include:

Parsing source code
Running language analyzers
Building dependency graphs
Extracting application objects
Generating architecture relationships

CARL performs the actual code analysis work behind the scenes in Imaging V3.

The CARL engine is not present in Imaging V2,

In Imaging V2, analysis is performed by:

CAST Console
CAST AIP Core analyzers

In Imaging V3, the architecture changed and CARL replaced the traditional analysis runtime.

How does the analysis workflow differ between V2 and V3?

Imaging V2 Workflow

Source Code > CAST Console > AIP Core Analyzers > CAST Database > Imaging Viewer

Imaging V3 Workflow

Source Code > CARL Analysis Engine > Imaging Core Services > PostgreSQL Storage >

Imaging UI

Does Imaging V3 support container-based deployments?

Yes. Imaging V3 is designed to run in:

Docker environments
Kubernetes clusters
Cloud platforms

Imaging V2 typically runs on local servers or Windows-based installations.

Can Imaging V3 run multiple analysis engines?

Yes. Multiple CARL analysis nodes can run in parallel, allowing large applications to be analyzed faster.

Example:

Analysis Node 1 → CARL

Analysis Node 2 → CARL

Analysis Node 3 → CARL

This improves scalability compared to V2.

What are the main functional improvements in Imaging V3?

Major improvements include Container-based analysis, Scalable Micro services based architecture, Easier automation, Advanced CI/CD Integration, Cloud-ready deployment, Faster analysis for large applications