Configurations is a redundant, overloaded term (see what I did there?) when it comes to Visual Studio SSIS projects. When people talk SSIS and configurations mostly it is regarding runtime configurations which allow values to be passed into an SSIS package. That’s not what these posts are about.
Instead these three posts are about Visual Studio Project Configurations and how they work (or don’t work) with SSIS.
- What are Visual Studio Project Configurations
- SSIS 2008 Project Configurations
- SSIS 2012 Project Configurations
So What are Visual Studio Project Configurations? First, let’s define what configurations are, taken from here:
A configuration is a build type described with a named set of properties, typically compiler switches and file locations. By default, new solutions contain two configurations, Debug and Release.
The three primary areas that can be set via project configuration are:
- Building
- Deployment
- Output
The term “areas” is used because configuration options actually change depending on what type of project is being configured.
Conceptually these allow settings to be predefined for Debug, Dev, QA, UAT, Production and whatever other environment(s) may exist. Then with a simple drop down box to select what environment needs to be applied to the project and wham bam, all those predefined settings are applied. The configuration only needs to be set up once, plus can be shared between all members of the team. All in all pretty powerful.
However as we explore these in the next couple posts, we will find out that they don’t always play well with SSIS projects.
The post SSIS Project Configurations appeared first on Aaron Lowe.
