SSIS File System Task Editor closes unexpectedly

Copying and pasting SSIS packages can lead to a few issues. It sounds like you have simple packages - a dataflow with a source to destination. Generally, those don't have the hangup I've run into but I have seen situations where people were inconsistent in their definition of data types. Email - varchar(40), varchar(80), varchar(120), nvarchar(256) all in the same database, just in different tables. What can happen is that you first build your package using the 80 size. When you copy/paste and fix your source table, the editor may not pick up on the data size change when you goto the 40 table because it fits within the old sizing. But I've also seen the reverse - it might not pick up the increased size. Resolution isn't horrific, just change your query to select 1 AS x, let it set the metadata and then fix your query back to the proper select.

As Dave suggested, this task is ideal for an entry level Biml task. In fact, as along as you don't mind not having your explicit source query, my Biml replicate-o-matic is pretty much exactly what you're describing. Earlier incarnation is on SO and I'm linking to it to hedge against link rot.

If you like your approach, you can keep your approach. But, save yourself the clicking and dragging in your destination and replace it with six clicks: three right, three left. In your mappings tab, right click to bring up this context sensitive menu

Left click "Select All Mappings"

Right click and the left click "Delete Selected Mappings"

Right click and then Left click "Map Items by Matching Names"

I've resolved this. I installed the SSDT Feb update and targeted the version to SQL Server 2014, as suggested by Dave. I did have to tweak one script (unrelated package and script task) but then I managed to build and deploy. It's processing happily.

The Pre/Post Execution messages were all clean, but based on the advice on this question, I did analyse them in more detail so I've picked up a bit of knowledge here too!

Thanks for all the feedback, especially the comments from billinkc:

Look at the Execution Log for the package that has run on the server. My guess is that you will eventually discover there is a permissions issue but at the moment, it could be a number of places.

Specifically, what I'd look at is the Pre/Post execute entries in the Execution report. that would indicate whether the Script task ever fired. If there's no pre/post, then look for informational events related to your Foreach Loop Containers.

If a permission issue prevents the FELC from seeing a directory, it does not error out. Instead, it fails gracefully, which trips up 99.999% of the population

If it is a validation issue (somefile.txt doesn't exist when the package begins b/c it determines what the current file is), then you will want to set the DelayValidation property to true on the Connection Manager and any tasks that reference said Connection Manager.