# Dax Studio: writing and profiling DAX inside Power BI and Analysis Services > Dax Studio is a desktop tool for writing, running and analysing DAX queries against Power BI Desktop, Power Pivot for Excel and Analysis Services Tabular. Its repository documents the build and release engineering rather than the product. **DaxStudio/DaxStudio** — DAX Studio is a tool to write, execute, and analyze DAX queries in Power BI Desktop, Power Pivot for Excel, and Analysis Services Tabular. - Repository: https://github.com/DaxStudio/DaxStudio - Website: http://daxstudio.org - Stars: 835 · Forks: 165 - Language: C# - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/daxstudio-daxstudio ## A DAX workbench for three different tabular hosts Dax Studio is a tool to write, execute and analyze DAX queries across three hosts: Power BI Desktop, Power Pivot for Excel, and Analysis Services Tabular. That trio is what defines its scope. Each host exposes a model, and each gives you a different amount of feedback about a query, so a separate client that can attach to any of them and profile the same expression is a distinct need rather than a convenience. The repository, though, is not the product documentation. Its README is short and talks entirely about building, branching and releasing, with the project homepage at daxstudio.org carrying the user facing material. What follows in the repository is a developer's view, which is where the interesting engineering decisions are visible. ## Building means a nuget restore in Visual Studio 2022 The build story is short because the project made it so. All of the dependencies for Dax Studio are available as nuget packages, so a nuget restore is enough to build the solution in Visual Studio 2022. There is no submodule to initialise and no hand assembled toolchain in the README, and the presence of a .nuget directory plus a build.msproj at the root confirms the package based layout. The root also carries several application configuration files named for different Visual Studio generations, app.2014.config, app.2016.config and app.2017.config, which is the usual pattern for a WPF application that has to keep its binding configuration working across IDE versions. Continuous integration runs through azure-pipelines.yml, while the AppVeyor badges at the top of the README report the status of both long lived branches. ## develop carries the work, master carries the release The branch policy is the clearest thing the README states. The develop branch contains the current development build of the code, including any new features, and the master branch only contains the code for the last stable release. Contributors preparing a pull request should create a feature branch off develop, and the project merges from develop into master when doing a public release. This is a two branch model with a short master, which means a bug fix that has to ship to users has to travel from a feature branch into develop, sit in the development build, and then ride the next release merge to reach master. The master branch is therefore a release artefact rather than an integration branch, and treating it as the everyday target is the mistake the README warns against. ## Preview builds carry a separate version line and an opt-in The release side is documented in docs/release-process.md, which covers the stable and preview release processes, the CurrentReleaseVersion schema, and how users opt in to preview builds. The repository root contains CurrentReleaseVersion.xml, while the README refers to the CurrentReleaseVersion.json schema, a small discrepancy that will cost a contributor an hour of hunting if they follow the prose literally. The tagged releases show how versioning works in practice. Around the same day in September 2026 the project published v3.7.0.1254-pre and v3.7.0.1253-pre, both carrying a pre tag, and v3.7.0.1252 on 2026-09-04, which also appears with a pre tag in its release title. The four part version number with a build counter is how a desktop application ships many builds while telling users whether they are on a preview. ## Shipping targets: an installer folder, Chocolatey and winget The repository root is organised around the different ways the application is delivered. There is an installer directory for the packaged installer, a chocolatey directory for the package manager feed, and a winget directory for the Windows Package Manager community repository, which is where most current Windows desktop apps are now discovered. The build entry points mirror that spread: build.cmd and build2.cmd for ordinary builds, build_portable.cmd for a portable output, build_preview.cmd for the preview channel, build_signed.cmd for a signed binary, and CleanAll.bat to reset the tree. A setup-build-env.ps1 script prepares the machine. Two testsettings files, Local.testsettings and TraceAndTestImpact.testsettings, cover different testing modes, and a debugging.md document plus a debugging directory hold the instructions for stepping through the code. ## Licence terms live in a rich text file, not a standard one The licence situation is worth checking before you build on the code. The repository is listed with a custom licence that GitHub cannot classify, and the root holds license.rtf rather than a standard LICENSE text file, so the terms have to be opened and read rather than recognised from the badge. That is the only unusual licensing artefact in the tree. On the maintenance side, the repository is not archived and the last push was on 2026-10-05, with the tagged preview releases dating from 2026-09-06, so the tree is being worked on. The remaining root directories, .plans/, docs/, src/ and tests/, describe the shape of the project itself: planned work, documentation, the C# source and the test suite, all sitting under a solution whose user facing documentation lives on the project site rather than in the repository. ## Conclusion Dax Studio suits a DAX developer who needs to query and profile a tabular model outside the host application's own query window, and who is comfortable with the Windows tooling around it. It does not suit a Linux or macOS user, since the build and packaging described in the repository assume Windows and Visual Studio. Before contributing, branch from develop rather than master, and read docs/release-process.md, since the version file that governs preview builds is described in the README as CurrentReleaseVersion.json while the repository root actually carries CurrentReleaseVersion.xml. ## FAQ ### What is Dax Studio used for? It is a tool to write, execute and analyze DAX queries in Power BI Desktop, Power Pivot for Excel and Analysis Services Tabular. ### How do I build Dax Studio from source? All dependencies are available as nuget packages, so a nuget restore should be enough to build the solution in Visual Studio 2022. The root also holds build.cmd, build_portable.cmd, build_preview.cmd and build_signed.cmd for the different outputs. ### Which branch should I create a feature branch from for a pull request? From the develop branch, which contains the current development build including new features. The master branch holds only the code for the last stable release. ### How are preview builds of Dax Studio handled? docs/release-process.md covers the stable and preview release processes, the CurrentReleaseVersion schema and how users opt in to preview builds. Recent tags such as v3.7.0.1254-pre and v3.7.0.1253-pre show the preview line in use. ### Where can I find the user documentation for Dax Studio? On the project homepage at daxstudio.org. The repository README focuses on building, branching and releasing, with further detail in docs/ and debugging.md. ## Sources - [DaxStudio/DaxStudio on GitHub](https://github.com/DaxStudio/DaxStudio) - [Issues](https://github.com/DaxStudio/DaxStudio/issues) - [Project website](http://daxstudio.org) - [README](https://github.com/DaxStudio/DaxStudio/blob/master/README.md) - [Releases](https://github.com/DaxStudio/DaxStudio/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daxstudio-daxstudio