Goal
Our goal is to be able to run packages from another application, outside of BIDS (Business Intelligence Development Studio. In particular, we want to run these packages from a website.
Problem
Ok, so we know what we want to do. Let's try it.
We use VS2012 to build our SSIS package, because that's the development tool that our company uses.
We install Integration Services from SQL Server, so that we can "run" our packages locally.
We built a website in ASP.NET MVC, using VS2013 and wired up everything. We put our packages into a directory, and loaded the package names into a list. We show that list to a user, and allow them to choose one to run.
We research how to run packages from code:
http://technet.microsoft.com/en-us/library/ms136090.aspx
This shows us how to run a package locally. We add the appropriate references to "Microsoft.SQLServer.ManagedDTS" 12.0 (because that's the newest).
Great! Let's run it.
Uh oh! We get an error.
"To run a SSIS package outside of SQL Server Data Tools you must install..." - there are many different types of this error.
But Wait!? I have Integration Services installed. I am doing exactly what the example shows. Why is this error here?
Google...Google...hours go by...Google...Google
Everyone says the same thing. Install Integration Services.
Spoiler -> That's not the issue.
Alternative
So, I changed my approach. I was going to CREATE package programmatically, and then, I could run them programmatically.
I use VS2013 and create a wrapper library for SSIS basically. It's nice, with interfaces and dependency injection, but that's not important. I take a package that I created by code, and import it into VS2012 BIDS. I wanted to see what it looked like on the GUI.
Uh oh! We get an error.
The version number "8" is higher than the version number used by the system -> "6".
You may know where this is going, but it took me a while.
So, I, relatively quickly, realized that the version number of my library was different, so I changed it to 11. I was using 12 in VS2013 and VS2012 needed 11.
Also, in case you were wondering, the 11 version of the XML in the package has some differences other than the version number. They have longer property values and such.
So, that fixed the import issue. That should have rang my alarm bell, but it didn't. I continued for a while, later realizing that I was wrapping SSIS. Hey, I was stuck. I didn't know where to turn next. AND, it wasn't my idea to make packages programmatically; it was a task given to me, so...
Then, it hit me. I wonder if I change the version of the DLL that I'm using, will the package work.
Yes, it will.
TL, DR : Make sure the version of "Microsoft.SQLServer.ManagedDTS" that is used to run the SSIS packages is the same as the one used to make them.
