Hi,
This is really odd and I can replicate this. I start with a vs 2015 built ssis package. We have recently upgraded to vs 2017 enterprise, ssdt 15.1.x, ssis 15.x if I change the label on a task and move the .dtsx file to azure, it runs, so a vs 2017 built .dtsx file runs on our azure. If I delete one of the current dtsconfigs and add a new one, move that package to azure and run it, it fails with a teradata login error. Can anyone think of a way that specifying a laptop dtsconfig file can cause an azure runtime execution error? The dtsconfig files in the azure environment are completely different than our laptop dtsconfig files, we've used them in 1000's of executions so they seem correct.
In my mind a dtsconfig file just sets variable values for a given ssis session or execution. A dtsconfig file does not affect the executing logic or code in a .dtsx package. How specifying a dtsconfig file (I don't even exit and get back in to get the values from the laptop dtsconfig) can affect the azure runtime environment is beyond me.
Our Azure is the in house kind of Azure, probably pretty old (a couple of years old).