How Bicep is bringing back IntelliSense to Microsoft Desired State Configuration

IntelliSense is dead in Microsoft Desired State Configuration (DSC). At least when you start creating configuration documents and declare their properties for the resource you want to use.

When Microsoft DSC launched, it introduced a cross-platform command-line interface utility. However, this evolution compared to PowerShell DSC came with a trade-off: the loss of IntelliSense support that developers had grown accustomed to.

The bicep-types-dsc experimental project tries to restore this experience by leveraging Bicep's type system and its experimental target scope desiredStateConfiguration.

In this blog post, we'll dive into what was lost in the transition, how Bicep's type system can address this, and how the technical implementation has worked so far.

The IntelliSense problem

The PowerShell DSC v1.1 and v2.0 IntelliSense feature has been amazing to this day. You would fire up VS Code (or PowerShell ISE), start declaring the Configuration keyword, import the module containing DSC resources, and declare your resource.

When the resource was declared, you could press Ctrl+Space to trigger IntelliSense, and the available properties are displayed:

Trying to do the same in a configuration document targeted for Microsoft DSC doesn't give you the properties you're looking for:

This gap is painful when working with complex resources that have dozens of properties. Without IntelliSense (or GitHub Copilot), you need to:

• Remember exact property names.
• Look up valid value types for each property.
• Constantly look up reference documentation.
• Potentially discover configuration errors at runtime.

Now, editors like VS Code aren't entirely unaware of the schemas used in Microsoft DSC. With the enhanced authoring schemas available in Microsoft DSC, you can get some IntelliSense support. It allows you to hover over documentation, get snippets, and receive better messages for the configuration document structure.

However, these enhanced schemas focus on the configuration document format itself, not the individual properties of DSC resources. You still need to manually look up the resource schemas to know which properties are available and what types they expect.

And this only works for command-based DSC resources. Not the adapted ones. So the question becomes: how will IntelliSense get back to our lovely editors?

Enter Bicep's ecosystem

The answer comes from an unexpected place if you're not up to date on the latest developments in Bicep. Since Bicep's v0.34.44 release, a new experimental feature flag was added: desiredStateConfiguration. You might already be wondering what Bicep has to do in Microsoft's DSC landscape, since it doesn't focus on Azure resources.

With this experimental support, Bicep introduced a new target scope specifically for Microsoft DSC. Here's the interesting part: while you author configurations in Bicep, the files compile to JSON. This is precisely the format DSC's engine is looking for. Bicep becomes an authoring layer that bridges the gap between developer experience and runtime requirements.

But that didn't solve the entire problem. Bicep alone doesn't automatically know about DSC resources and their properties. Out of the box, it only has type definitions for Azure resources. To get IntelliSense for DSC resources, it needed teaching. And that's exactly what Andy Jordan did.

The bicep-types-dsc project was brought to life. This project works by:

• Generate Bicep type definitions from DSC resource manifests.
• Create a Bicep extension package that registers these types
• Leveraging Bicep's DSC target scope to enable authoring DSC configurations, giving the IntelliSense developers look for.

When you author a DSC configuration in Bicep with this setup (using targetScope = 'desiredStateConfiguration' and loading the extension via bicepconfig.json), you get:

• Property completion: All available properties appear as you type.
• Type validation: Bicep verifies that values match the expected types (e.g., string, integer, boolean, etc.).
• Inline documentation: Property descriptions defined in the schema appear as tooltips.
• Error detection: Invalid properties or type mismatches are caught before you apply the configuration document.

This restores the developer experience that was lost during the transition. Now, remember, the bicep-types-dsc is in an experimental state. The package isn't officially published, but it demonstrates the advantages it can provide.

In the following sections, we'll look at its advantages, how it works, and its current limitations.

The ARM function advantage

Beyond the restored IntelliSense with these types, Bicep integration offers another capability: access to Bicep's built-in functions. These are derived from Azure Resource Manager (ARM) template functions. This functionality never existed in PowerShell DSC.

PowerShell DSC allowed you to use PowerShell expressions within configurations. But these were evaluated at authoring time. Microsoft DSC's JSON or YAML configurations are essentially static, and during compilation, Bicep converts these to proper ARM functions.

When the engine detects ARM functions, they're evaluated at runtime. Let's take a look at how that would look behind the scenes. Imagine the following Bicep file:

// main.bicep
extension dsc
targetScope = 'desiredStateConfiguration'

param companyName string = 'MyCompany'

resource registry 'Microsoft.Windows/Registry@0.1.0' = {
  name: 'SetInstallPath'
  properties: {
    keyPath: 'HKLM\\Software\\${toLower(companyName)}'
    valueName: 'InstallPath'
  }
}

Running the above example with dsc config get --file main.bicep compiles the file to JSON by running bicep build main.bicep --stdout.

Then later in the process, you can see DSC evaluating the expression:

This perfectly gives you the whole authoring experience without writing complex JSON expressions. It allows you to build your configuration document using Bicep dynamically.

But it still didn't fully answer the question of how Bicep knows about DSC resources like Microsoft.Windows/Registry in the first place? How does it provide IntelliSense for their properties and validate their types? That's where the type generation comes in.

How it works

The magic behind this IntelliSense experience is the bicep-types-dsc generator. This performs a transformation:

1. It discovers all registered resources using dsc resource list.
2. For each resource, it retrieves the JSON schema definition running dsc resource schema.
3. It maps JSON schema types to Bicep's type system.
4. It packages these types into a Bicep extension type (.tgz file).

Once generated, the extension is referenced in your bicepconfig.json file. Any Bicep file with the extension dsc and targetScope = 'desiredStateConfiguration' keyword defined, gains the IntelliSense for all registered DSC resources.

Current limitations

The bicep-types-dsc is gaining traction, but it's experimental. The current limitations are:

• Not all JSON schemas map cleanly to Bicep types.
• Adapters are not supported.
• Bicep's DSC support requires experimental feature flags (don't use it in production).
• The generated Bicep files don't yet compile to the final DSC configuration documents format (you've to transform the outputted JSON file from bicep build).

However, as Bicep's extensibility matures, so does DSC integration improve. We can already see its first-class authoring experience in VS Code and the reusability of Bicep's function.

Conclusion

The bicep-types-dsc project illustrates how worlds collide together. It bridges the gap of IntelliSense. By leveraging Bicep's type system and extensibility, you can restore the authoring experience developers expect while benefiting from new capabilities through ARM functions that were never available in PowerShell DSC>

For teams adopting Microsoft DSC and already working with Azure resources, this approach offers a compelling path forward: maintain the cross-platform benefits of Microsoft DSC while writing your configuration documents in Bicep with IntelliSense-driven configuration authoring.

Whether this becomes an official Microsoft solution or remains an experiment, it highlights an important principle: developer experience matters.