[RESOLVED] SSIS Loading config from wrong location

I've got an SSIS package that I'm working with that I've created a configuration file for. It contains the connection string for both the database server and a flat file to use and import. So far so good. Or so I thought.
In the package, I created a new configuration file using the Package Configuration Manager and created an XML file from the settings I needed. I'm trying to simplify the deployment process and reduce the need to have VS installed on the server in order to edit the connectionstrings for every client. Made some other changes, saved, copied the dtsx and .config file to my local server location, opened SSMS, created a job, setup a schedule, set the security so that it would run properly... and ran it... viola! IT WORKED! And there was great rejoicing. And then of course, I started my real testing. I renamed the flat file, and opened the config file I had deployed, changed the connection string to match the file's name... saved. Closed. Ran job. Failure... can't find the file. Of course the file it reports that it cannot file is the OLD file... but I changed it in the config file! Sooooo.... On a whim, I changed the config file in my development folder (so now it points to testfile.csv), saved it, ran the job and wouldn't you know it? It threw an error saying that it couldn't find file testfile.csv !!! So it's not even loading the config file from the directory where the dtsx is, it's loading the file from the full path where I linked to it in VS! But that's not what I want. I tried to make it relative by changing the path to ".\SSISPackage.config" ... and it immediately changed it back to the full, complete path.

How do I make the $#%^$!# thing recognize the config file in the same folder the dtsx package is in? I even tried to add the package through the Add Configuration in the SQL Job properties, so for that hasn't helped either.

I need to make this deployement as simple and easy as possible as often we're going to be dealing with cases where we have to ship the files to someone with step by step instructions on how to configure and deploy it. At the moment, it's a bit complicated because it involves editing with VS which I'd like to avoid (which would probably also make our hosting people happier).

-tg

Ha! Figured it out. I renamed my development folder... and like that, it started looking in its own folder for updated configuration information. So apparently the answer is: If you're going to do deployment testing on the same box as development, block the patch to the original config file or it will pick it up.

-tg

I've noticed that SSIS has a strange recall of things that it should not. If you have an output from a VIEW, for instance - and you add a column to the VIEW. SSIS balks at that...

Yeah, it can be tempermental at times. Luckily I caught this and it forced me to do some more testing with it on the security side that revealed a few holes I had to plug. I'm just happy that it didn't take all day and I still had time left on the project. I get to do it all over again tomorrow as I push it out to QA and get to test my deployment instructions to see how good they really are.

-tg