HTML & CSS

Add SCSS Compilation to a Visual Studio Build Workflow

Run a project-owned Sass build through MSBuild, preserve compiler failures, and verify generated CSS is present before the web application is packaged.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Make SCSS compilation an explicit build step

A Visual Studio workflow can compile SCSS by invoking a project-owned Sass command before the web application is built or packaged. The important boundary is explicit: the compiler reads maintained SCSS and emits CSS that the application then includes. Editor support, application compilation and asset generation are separate operations unless your project deliberately connects them.

First confirm that the Sass command works outside the IDE. Keep the compiler as a pinned project dependency and record the input and output paths. If a task works only through a personal extension, a teammate’s machine or release runner may not reproduce its result. An ordinary command is easier to run and diagnose in each environment.

Define a one-shot npm script

The following script compiles Styles/build.scss into wwwroot/css/build.css. Merge it into the package file that owns this web project, after installing the official sass package through the project’s dependency workflow.

{
  "scripts": {
    "css:build": "sass --no-error-css --no-source-map Styles/build.scss wwwroot/css/build.css"
  }
}

$border: #334155;

.build-card {
  border: 2px solid $border;
  & strong { color: $border; }
}

Run npm run css:build once and inspect the two generated selectors. The card border and nested strong text should both use #334155. Change the variable to #7c3aed and rebuild to check that the current source, rather than an old output file, is driving the result.

Wrap the command in a dedicated MSBuild target

For a small explicit integration, place build-css.proj beside package.json with the following contents. This is a separate build entry point, not a replacement for the application’s .csproj file. The working directory is derived from the location of this project file so the npm script resolves the intended paths.

<Project>
  <Target Name="BuildCss">
    <Exec Command="npm run css:build"
          WorkingDirectory="$(MSBuildThisFileDirectory)" />
  </Target>
</Project>

Invoke the target with the .NET SDK’s MSBuild command, or through the equivalent MSBuild tool used by your project. Node.js, npm and the installed project dependencies must be available to that process. The wrapper does not install missing dependencies or silently replace your Sass version.

dotnet msbuild build-css.proj -t:BuildCss

Keep compiler errors visible to the build

The MSBuild Exec task runs the command and can fail the target when the command fails. Do not suppress its exit status merely to make an application build appear successful. An unfinished SCSS declaration should stop this asset step, and restoring valid source should make a subsequent run succeed.

Avoid using Sass watch mode inside this target. A watcher is intended to stay alive during editing, so it is unsuitable for a build step that must finish with a clear success or failure. Keep watching in a separate development terminal and use the one-shot command for build and release verification.

Run asset generation before application packaging

In the simplest release pipeline, run dependency installation, this CSS target, and then the web application’s build or publish command in that order. Stop if any required step fails. Generating the stylesheet before evaluating the application project also avoids assuming that a file created later was included by an earlier file glob.

If you integrate the command directly into an existing project’s target graph, choose the hook according to that project’s build and publish behavior. Microsoft’s build-extension documentation explains target ordering. Do not paste an arbitrary BeforeTargets value into every project and assume it covers design-time builds, incremental builds and publishing identically.

Inspect the published CSS artifact

Check that the final publish directory contains build.css with the current border color. A successful Sass command alone does not establish that the web application packages the output. Review the application’s static-content item rules and URL references, especially when generated files are excluded from version control or are created in a clean release environment.

Then load a page that uses .build-card and inspect the requested CSS and computed styles. Test both the card and its strong descendant. If the source and published output agree but the browser differs, check the served URL, caching and competing declarations rather than modifying the compiler command without evidence.

Keep compiler and minifier responsibilities clear

Dart Sass resolves the SCSS variable and nesting in this example. The local CSS minifier only processes CSS after that compilation; it does not run MSBuild or inspect a Visual Studio solution. Use it for a focused output inspection when useful, while leaving the repeatable project build responsible for generated assets.

Record the compiler version, command, source entry and output path with the project. That makes a later build failure diagnosable and prevents an IDE-specific convenience from becoming an undocumented requirement for publishing the application.