Skip to main content

SSIS Project Parameters from Biml

The Question​

Neither BI Developer Extensions nor BimlExpress emit SSIS project parameters from Biml as a standard feature. Workarounds exist, but the missing native support is intentional. The reason comes down to the file format that SSIS uses for project parameters and the user experience that would result from overwriting it.

How Package Generation Works​

When the Biml engine emits an SSIS package, it overwrites a single .dtsx file. Each .dtsx file holds exactly one package, so an overwrite is contained: only the package being generated is touched, not unrelated packages. BIDS Helper and BimlExpress also present a checklist of every package that is about to be overwritten before the operation runs. A user who notices that a generated package collides with a hand built one can cancel the operation. Source control provides one more recovery layer if a manual change still gets overwritten.

The worst case is small: the user loses a few unsaved manual edits to a package that happens to share its name with a generated package. The common case is no loss at all.

Why Project Parameters Are Different​

Project parameters are not stored one per file. Every project parameter for the entire project lives as an XML element inside a single Project.params document. There is no clean overwrite story for that file.

Three approaches all break:

  1. Overwrite the file. Generation would replace any project parameters that were created manually. Most teams are not pure Biml shops, so manually authored parameters are common and silently losing them is unacceptable.

  2. Merge new parameters in. Inserting Biml generated elements into the existing Project.params solves the first generation, but not subsequent ones. When a parameter is renamed or removed in the Biml source, the engine cannot tell whether the matching parameter in Project.params was hand created or generated by an earlier run, so renames produce orphans rather than updates.

  3. Tag generated elements with annotations. Visual Studio and SSDT strip unknown attributes from Project.params on save. Even if they did not, diverging from the standard file shape risks breaking other tools that read or write the same file.

Unsaved manual changes to Project.params make the situation worse. The SSIS project system does not expose pending edits to add ins until the file is saved, so a generation step cannot detect them. A force save before generation would be required, and even then the merge problems above still apply.

Why Not an Opt In Setting​

The only scenario that works cleanly is the pure Biml workflow: every project parameter comes from Biml, nothing is created by hand, and overwriting Project.params is always safe. An opt in setting could enable that mode, but it would benefit a small minority of projects and create new failure cases for everyone else who forgot to turn it off on a mixed project. The risk of accidental data loss outweighs the benefit, so the feature is intentionally absent.

The Practical Workaround​

Teams that need generated project parameters can build them through a separate Biml file that emits the Project.params XML and write it themselves, accepting the merge risks above as a known cost. The native add ins stop short of this on purpose.