• Well, I'm a bit late to the party here, but have to say "portable DTS packages" is pretty much of an oxymoron. 

    I'm a former OO developer where we used DTS only to import/export data.  The packages were invoked from VB code and run-time properties set via the COM interface.

    I'm now doing data warehousing using DTS only.  We're not allowed to touch the production server, so we have to develop the packages on a Dev box and turn them over to the DBA.  Until I came on board and suggested Dynamic Properties, he was almost rewriting the fool things.  While the DPs have helped a lot, I still find them a PITA to use, especially through the DTS designer interface.  That's why I typically save the package to a .BAS module then load to an Access DB where I add the Dynamic Properties task via a VB proc I wrote.  Also the only sure way to test the property mapping is to execute the task, then go look at your objects/properties.  It's extremely annoying to me that when you view the DP task, it doesn't show you which object/property the DP is mapped to (using .INI files for connection info).  Also the hard-coded path to the .INI file names means we have to map our drives exactly as on the production server so the package can find them.  That's why I'm looking at replacing the DP/.Ini file with an ActiveX script that reads an XML file from whatever the DTS file path is and populates global variables.

    At least in SQL 2000, I find DTS is way too server and object-centric to be portable or scalable.  That's why in all of my past uses, the packages were kept dumb as a rock, no business rules at all were allowed to reside in them, just firehose data in and out, let the VB code and stored procedures do the brain work and use .UDL files for all DB connections.