Skip to content

Why can’t I create SSIS Project Parameters from Biml?

Biml (Business Intelligence Markup Language) - Why can't I create SSIS Project Parameters from Biml in BimlExpress or BIDS Helper?BIDS Helper and BimlExpress does not support creating SSIS project parameters from Biml out of the box. There are workarounds (and I have previously blogged about my solution for creating project parameters from Biml), but why is this not a standard feature in BIDS Helper or BimlExpress? Many people have asked about this, so I sat down with Biml creator Scott Currie (@ScottCurrie) to get the full story.

Why doesn’t BIDS Helper or BimlExpress emit SSIS project parameters from Biml?

Well, technically it could, but it shouldn’t. The user experience would have serious issues, leading to confusion, frequent errors, and the potential for data loss. How can that be?

First a comparison to SSIS packages

When the BimlEngine emits a package, it knows that it is overwriting the entire .dtsx file. In general, this is safe, because each .dtsx file contains exactly one package. There is no risk that by overwriting one .dtsx file, that it might overwrite both the desired package and some other unrelated package. One package per file – good.

Furthermore, since it is one package per file, BIDS Helper or BimlExpress can present you with a convenient checklist of all the packages that are about to be overwritten. Maybe you made a mistake in your BimlScript code and accidentally generated a package that has the same name as a painstakingly created manual package. Or maybe you noticed it in the overwrite list. Maybe not. Either way, you had the opportunity to prevent that bad thing from happening. Also, if you are using source control and checked in recently, you can revert the changes and restore your manual package.

Finally, if you have a package open with unsaved edits, not much changes from the above scenarios. The very uncommon worst case is that you lose a small number of changes that you made to a manual package since you last saved – and only when you also made the mistake of generating a package with the same name as your manually created package. The common case is that you lose some manual changes (e.g. moving boxes around on the design surface) that you never intended to preserve in the first place.

How are SSIS project parameters different?

SSIS project parameters do not work the same way as SSIS packages. All project parameters are stored as XML elements in a single XML document for the entire project called Project.params. This is the core reason why packages have a good overwrite story while parameters have a poor overwrite story.

It should be obvious that BimlExpress can’t just overwrite your Project.params file. Of course, BimlExpress would be creating the parameters you specified in your BimlScripts, but it would also be overwriting any parameters you might have created manually. If you are a Biml purist, you might not care about this, because you would be fine with creating all of your project parameters through Biml. Unfortunately, most Biml users are not Biml purists – and even fewer development teams are Biml purists.

The next logical thought is to avoid the overwrite problem through merging. Certainly BimlExpress could insert the generated project parameter elements into the existing Project.params file. Duplicate values could be ignored. Unfortunately, this only solves the problem for the very first version of your generated Project.params file. What happens when you change the names of the parameters in your Biml code or delete some of them? The BimlEngine has no way of knowing that a given parameter in your Project.params file was deleted or renamed and not just created by hand. This would lead to a potentially large number of orphaned project parameters that you would need to manually manage.

Perhaps, you might suggest, we could add some form of XML annotation to the Biml-generated elements in the Project.params file to solve or at least improve the merging capabilities? That could be a great solution, but Visual Studio / SSDT strips any additional properties you add whenever it saves the Project.params file. Even if Visual Studio / SSDT preserved those additional annotations, this could still be a risky strategy, since other Microsoft and 3rd party tools have the potential to fail or otherwise misbehave if the BimlEngine diverges from the standard accepted encoding for the Project.params file.

This gets even worse for project parameters in the scenario where the user has unsaved manual changes to the Project.params file at the time when generation is performed. These unsaved changes are impossible to detect and merge because the SSIS project system does not expose those changes to add-ins until they have been saved in the Project.params file. This means that parameter changes would have to be force-saved prior to any Biml generation, but would then still suffer from all of the above issues.

Can’t you do anything? Even with an optional setting?

Based on the above analysis, the only scenario that doesn’t create more user confusion and frustration is the Biml Purist scenario. For this case, we might be able to offer an option to always overwrite the Project.params file, but that would satisfy a minority of users and would also be very frustrating in cases where you forgot to turn it off for non-purist projects. Our thinking is that it is not worth the trouble it might cause to add this option.

Thank you, Scott!

Scott CurrieThank you to Scott Currie (@ScottCurrie) for taking the time to give us such a detailed explanation! I really appreciate it, and I hope this helps all of you Biml users who have been wondering why you can’t create SSIS project parameters from Biml. (Well, you can, but as you have probably realized by now – it can be risky.)

Finally, both Scott and I would love to hear your thoughts on this. Would you like to see an optional setting? Is it worth the risk, especially when working with Biml-generated packages and manually created packages? Is it worth the risk when working in mixed development teams?

What do you think?

Published: Last Updated: Categories: BimlTags: ,

About the Author

Cathrine Wilhelmsen is a Microsoft Data Platform MVP, BimlHero Certified Expert, international speaker, author, blogger, and chronic volunteer. She loves data and coding, as well as teaching and sharing knowledge - oh, and sci-fi, chocolate, coffee, and cats :)


Hi! This is Cathrine. Thank you so much for visiting my blog. I'd love to hear your thoughts, but please keep in mind that I'm not technical support for any products mentioned in this post :) Off-topic questions, comments and discussions may be moderated. Be kind to each other. Thanks!

Just throwing this out as a thought, but if BimlExpress and BIDSHelper are prompting me that I’m overwriting a current dtsx file it would mean it does a file lookup in the SSDT project directory. So, could it include a check that says “there are dtsx files I’m not overwriting”? Then if that answer is “yes”, do not overwrite the project.params file.

In that sense, if a user is mixing manual package creation with Biml created packages you would likely see dtsx files in that project that are not being generated by Biml. If you don’t, then just prompt to overwrite the project.params file. [I would say the use cases where they accidently put the same name in Biml of a manual package name is on the extremem…and the developer should know better, but just my opinion :) ].

Thanks for your input, Shawn! A warning saying “hey, you’re trying to overwrite the Project.params file, are you sure you want to overwrite everything in this file?” would probably be good enough for most developers. I completely agree that some of these cases are edge cases, but I also understand that application developers (in this case, Varigence) need to make sure that they don’t blow up any existing solutions. It’s a tricky one :)

Pingback: Project Parameters In Biml – Curated SQL

I have a Project Parameter MailCc, I need this parameter in Send Mail Task Expressions for CCLine. In BIML if I define Expression tag @[$Project::MailCc] I am getting error – Variable @[$Project::MailTo] was not found. Exception type: ExpressionSyntaxException. Any thing wrong with the Expression tag?

Also the send mail task is not picking the Project SMTP connection, it is inserting GUID value when multiple packages are generated in loop. This needs a package Edit to correct the Connection on all Send mail tasks, which is a huge task based on the number of Packages. To overcome this problem, I forced a fixed GUID on Package Connection for SMTP and out side visual studio, finding the string SendMailTask:SMTPServer=”{}” in all dtsx files and replacing with the connection name. Am I doing anything wrong?

Pingback: BIML, where have you been all my life? - database dave

The reason explained for not implementing this feature sounds too silly for a code generator.

To handle the rename-issue, if Biml would allow you to store the Parameter ID (a guid) as well as the Name, then the parameter could be recognized by the GUID in the project.params file and a rename would be no problem. You would just have to generate a guid yourself to paste into the biml file, but that is doable.

What about the option of reading the existing projects.param into an XML variable, and manipulating the nodes of the variable, and then writing it back?

This way, if you don’t manipulate it at all, it gets read and then re-written the way it was. But before writing it back, we’d have the option of adding nodes (params), deleting nodes, renaming nodes or changing a node’s attributes.

Essentially, you’d be providing a scripting interface into the projects.param file.

Could something like this not work?

My suggestion would be for BIML to read the Project.params file before overwriting it and appending and BIML’d parameters to the existing file. Should the same parameter already exist BIML should not overwrite or edit it. This way any BIML purist (Hi, my name is Magnus and I’m a BIML purist!) experiencing that the BIML’d parameter wouldn’t be written would eventually find that there is already a manually created one and delete it. It would also make any mixed BIML’d/manually created projects safe from changes. You can use the Description field in the ssis parameter to auto-identify the parameter as a BIML’d one, e.g. “Automatically created by BIML – do not change”.

Hi! This is Cathrine (again). Just a reminder. I'd love to hear your thoughts, but please keep in mind that I'm not technical support for any products mentioned in this post :) Off-topic questions, comments and discussions may be moderated. Be kind to each other. Thanks!

Share Your Thoughts?