The current implementation of the Custom Scripts feature requires generation of a full all-in-one deployable package. Historically, these packages were created directly from Visual Studio via: Extensions → Dynamics 365 → Deploy → Create deployment package.

However, under the Unified Developer Experience (UDE), Visual Studio now generates incremental Power Platform deployable packages that are not compatible with the Custom Scripts feature. There is no indication in Visual Studio that the package type has changed, which leads developers to believe they are producing a valid deployment artifact when they are not.

Compounding the issue, the required build components to create a full all-in-one deployable package do exist locally as part of UDE installation, the ability to generate them has simply been disabled in the tooling.

This is not a minor tooling inconvenience. It creates a real operational gap for live production environments:

• Custom scripts are most often used in urgent or emergency situations where rapid remediation is required and critical business operations are halted until the issue is addressed.
• UDE currently removes the fastest response path that previously existed.
• This materially weakens UDE’s value proposition for customers already in production.
• It forces teams into slower, higher-risk, or higher-cost workarounds during critical incidents.

In effect, the platform is removing a previously available operational recovery mechanism without providing an equivalent replacement.

Currently there are only two workarounds both with significant drawbacks:

1. Maintain a Legacy Cloud Hosted Environment (CHE)
2. Infrastructure must be maintained despite being idle most of the time.
3. Many organizations must still patch and secure these VMs due to internal policy.
4. Ongoing cost for infrastructure used only during emergencies.
5. Build an Azure Pipeline Just for Script Deployment
6. One-time scripts must be committed to source control.
7. Each script requires its own model, rapidly cluttering repositories.
8. Cleanup introduces ongoing maintenance overhead.
9. Adds asynchronous steps to a workflow that is supposed to be fast and responsive.

Both options introduce cost, complexity, and delay into scenarios where speed is often critical to business continuity.

Microsoft’s stated direction is movement away from LCS/CHE-dependent workflows. However, today:

• UDE removes the existing method of addressing critical business issues in Production.
• No equivalent replacement capability exists, and is not planned to ever exist.
• Customers are forced back onto legacy infrastructure to retain the same operational flexibility and safety.

Two potential proposed solutions:

Option 1: Short-Term + Low Effort

1. Allow Visual Studio’s D365 extension to let users select which deployable package type to generate (Full vs Incremental) or build the package via a CLI Interface.
2. Since the required components are already installed locally, this change could be minimal.

Option 2: Long-Term

1. Enable the Custom Scripts feature to accept incremental Power Platform deployable packages.
2. This aligns with the current platform direction of moving away from LCS and removes dependency on legacy deployment patterns.