Blogs From The Inside Series.

Reproduced with kind permission from the blog of Kirk Haselden (MSFT)

We've been seeing a heightened interest among SSIS customers in writing custom components as they move from understanding the basic IS concepts to more advanced ones. The question has come up more than once, "Why is the UI code separated from the component code?" Not everyone notices this because you have to really dig deep into your system to notice it. To see what I'm talking about, take a look at a machine where SSIS is installed. Look in the %WINDIR%\Assembly folder. Under Microsoft.SQLServer..., there are a number of assemblies with identical names, one that has "UI" appended.

So, why do we do this?

Integration Services makes a pronounced distinction between design time and execution time. You see it in the dataflow/pipeline where there are design time and runtime interfaces and design time is when the components get built up, columns added and paths between them created.. In the runtime, certain operations are possible during design time, like changing the value of a read only variable or adding objects to collections that aren't available during execution time. We do this because of a few basic assumptions:

• You want your execution time behavior to be as fast as possible.

• You want to use as little memory as possible for non-essential activities during execution.

• You want your packages to be determinant, or in other words, execute consistently.

• You would rather not have non-essential assemblies on server systems.

The UI assemblies house the "UI" portion of a component that is only visible when you're building the package in the designer. If the code for the UI were in the same assembly, everytime you ran a package with that component, the UI assembly would also load up with the component. Memory consumption would go up and the working set would increase dramatically. We assume that you'd rather use every spare megabyte of memory for operations.

This separation also makes it easier to enable writing UI for components since some of our components are written in native code (for speed), but the UI is all written in managed code.

Aside from the advantages noted above, there is a psychological element to this pattern. Because the design time elements are separated from the execution time elements, it's logically easier to see the separation as you develop the component. It's also nice to know that it's not actually necessary to write custom UI for components. Tasks and other runtime components without UI may be edited via the property grid and pipeline components without UI may use the advanced editor. In fact, even some of the stock components that will ship with IS don't have a custom UI.

Finally, at some point in time, it's possible that Microsoft may provide a small footprint install or other similar setup distribution that will not install UI which will make it easier to distribute and have a smaller footprint, essentially by eliminating design time elements. There is _no_ official plan for this by the way. Right now it's just an idea getting tossed around. Any interest?

So, when writing your own custom components, you should consider separating your UI code into a separate assembly to get the benefits described here.

Hope this helps. Let me know.