We Keep Coding

Executing DTS Package from C# error Unable to cast COM object of type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.ApplicationClass'

I am working on a Console application where I am executing a SSIS package from c#.
Below is my code for the execution
private bool ExecutePackage(int _sid, int _pid, int _envid, string _connection, int _scheduleId)
{
bool isSuccess = false;
try
{
var dtPackagePath = HandlerFunctions.GetPackageInformation(_sid, _pid, _envid);
var DtsxPath = dtPackagePath.Rows[0]["dtsx_path"].ToString();
Application app = new Application();
Package package = null;
//Load the SSIS Package which will be executed
package = app.LoadPackage(DtsxPath, null);
//Pass the varibles into SSIS Package
package.Variables["User::mEnvID"].Value = _envid;
package.Variables["User::mPID"].Value = _projectid;
package.Variables["User::mSID"].Value = _sponsorid;
package.Variables["User::mConnectionString"].Value = _connection;
var results = package.Execute();
//Check the results for Failure and Success
if (results == DTSExecResult.Failure)
{
var err = "";
foreach (var localDtsError in package.Errors)
{
var error = localDtsError.Description;
err = err + error;
}
}
if (results == DTSExecResult.Success)
{
isSuccess = true;
}
}
catch (Exception ex)
{
isSuccess = false;
HandlerFunctions.WriteExceptionLog(_scheduleId, _sponsorid,
_projectid,
"Execute DTSX", ex.Message, ex.InnerException != null ? ex.InnerException.ToString() : string.Empty,
ex.StackTrace,
Convert.ToDateTime(DateTime.Now));
throw;
}
return isSuccess;
}
I have referenced Microsoft.Sqlserver.managedDTS.dll with this project and used the below in using attribute
using Microsoft.SqlServer.Dts.Runtime;
using Application = Microsoft.SqlServer.Dts.Runtime.Application;
I have also registered the ManagedDTS.dll using the GACUTIL in the system.
However, when i run the porgram I am getting error in the Application app = new Application(); and the error is as below
Unable to cast COM object of type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.ApplicationClass' to interface type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.IDTSApplication130'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{77A93073-6272-4FAC-BDB5-0C589385701C}' failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED)).
Can anyone help me with this issue?

The problem is two-fold. The first is that you are attempting to copy the DLLs for Integration Services piecemeal which is not how the installer would handle it. You would need to reproduce all the same actions of the SQL Server installer to get SSIS into a working state on the client machine.
The much, much bigger problem is that what you're trying to do is a violation of the licensing agreement. You have rights to develop SSIS packages for free. You do not have rights to run SSIS packages unless that server has been licensed for SQL Server. Even if you managed to solve the first problem, you have created a solution that puts your employer or the customer at a legal liability from Microsoft Licensing and that's not going to be an inexpensive resolution. Not Oracle licensing order of magnitude bad but still not pleasant.
To get the developer machine into the proper state, you need to get a copy of the Developer Edition of SQL Server. On the Instance Features screen, select
"Integration Services"
This will ensure all the correct assemblies are installed in the places they expect to be found.

Based on the error, it looks like the machine you are running this program does not have the SQL Server Integration Services installed.
You need SSIS to run SSIS packages ! (You can't run SSIS packages without SSIS)
You don't need to copy / register DLLs, you should try to refer the C# Assemblies installed by the SQL Server installer.
See: https://learn.microsoft.com/en-us/sql/integration-services/integration-services-programming-overview?view=sql-server-ver15
In my machine, I can see the C# assemblies at this location:

ssis package execution succeeds directly but fails via c# code

I have the following code which seems to works OK for executing an SSIS package from c# BUT every time the variable "Resp" returns a Failure even if the package passes when I execute it directly in SSIS.
Again, the package contains a Script component that writes to an SQL server table. All that works OK when the package is executed directly in SSIS but nothing happens when the same package is called via C# with the code below. I cant work out what I am doing wrong. help!
string packageLocation = #"c:\packageLocationPath";
Package pkg;
Application app;
app = new Application();
pkg = app.LoadPackage(packageLocation, null);
var Resp = pkg.Execute();

Detecting error
First you have to read the errors raised by the package. There are two options to detect these errors:
(1) loop over errors
You can loop over the package errors by accessing Errors property. As example:
if(p.Errors.Count > 0){
foreach(DtsError err in p.Errors){
Messagebox.Show(err.Description);
}
}
More information at:
How to get all errors of all SSIS packages in a solution
(2) Enable logging from package
You can capture all errors, warning and information from a package by enabling logging option:
Add and configure logging
Possible failure causes
Make sure that if you are using windows authentication to connect to SQL, that the user account used to execute the application via C# is granted to make a connection.
If the package is accessing a file system, make sure that the user has the required permissions to access these files

How do I run an SSIS package in SqlServer 2012 using vs2010?

Setup
I have a vs2010 SSIS package that I can run from visual studio. I have deployed it to my local 2012 server, and I can also execute that package from SSMS. In SSMS, I see the package here:
\Integration Services Catalogs\SSISDB\DAT_Load\Projects\UploadSYS.dtsx
Note: vs2010 does not give me an option to deploy a package anywhere but in a server, and then only in Integration Services Catalogs. Once in there, the MSDB database does not have an entry in the sysssispackages table.
Previously, it was adequate to bring up SSMS and run the package from there(right-click & execute). Now, I have to execute this from a C# web application. Furthermore, I need to trap progress messages and such through events.
Effort
I was able to determine how to set up the event trapping and I got myself to the point where I should have been able to execute the package from code:
public DTSExecResult ExecutePackage(string packageName, HttpContextBase context)
{
string ppath = ConfigurationManager.AppSettings[packageName + "Package"];
string pserv = ConfigurationManager.AppSettings[packageName + "Server"];
string puser = ConfigurationManager.AppSettings[packageName + "User"];
string ppass = ConfigurationManager.AppSettings[packageName + "Pwd"];
_context = context;
_pkgLocation = "";
_app = new Application();
_pkg = _app.LoadFromSqlServer(ppath, pserv, puser, ppass, _SSISEvents);
_pkgResults = _pkg.Execute(_connections, _variables, _SSISEvents, _log, null);
return _pkgResults;
}
Problem
I cannot locate the package. When I reach the LoadFromSqlServer statement, I receive an error that says:
Cannot find folder "\Integration Services Catalogs\SSISDB\DAT_Load\Projects\UploadSYS.dtsx"
The same thing happens for variations in the path (variable = ppath):
\Integration Services Catalogs\SSISDB\DAT_Load\Projects\UploadSYS.dtsx
\SSISDB\DAT_Load\Projects\UploadSYS.dtsx
\DAT_Load\Projects\UploadSYS.dtsx
etc.
Running this from the command line or a stored procedure is not an option.
So, can anyone tell what I am missing here? Does the Application object need to initialize something? Is this even possible?

Taking another bite at the problem but see Set SSIS database package path and SSIS Organization for background reading.
Until SSIS 2012, if packages were deployed to SQL Server, they lived in the msdb. The .NET API for interacting with them was the same across versions.
With the 2012 release of SSIS, we have two different deployment models. Package deployment, which is the "classic" model is alive and fully supported. The same code for running a package on 2005 will work for 2012 package deployment model projects. This is the Microsoft.SqlServer.Dts.Runtime Namespace
Your code is attempting to load a 2012 solution built using the "project deployment model" with the "package deployment model" API. This is the Microsoft.SqlServer.Management.IntegrationServices Namespace and the two don't mix.
Your options are to switch your project back to the Package deployment model or update your code. In the first linked question, I provided the VB.NET implementation for running an SSIS package in the SSISDB catalog. There is some way of running a .ispac file because I see the option in dtexec but I'm not seeing the specific method. This is mechanism VS/SSDT uses when it runs the packages locally.

the microsoft.ace.oledb.12.0 provider is not registered on the local machine

I have the following program in which i want to insert the values in MS-Access.I am getting the error "the microsoft.ace.oledb.12.0 provider is not registered on the local machine"
I have already installed the database engine as per suggestion of some developers, still i am getting the error.
I am writing the code on Vista machine with VS-2008 and MS-Access-2007.
Please help me to resolve the error
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
OleDbConnection con;
OleDbCommand cmd;
private void btnSubmit_Click(object sender, EventArgs e)
{
try
{
con = new OleDbConnection("Provider=Microsft.ACE.Oledb.12.0;Data Source=C:\\Users\\Satish\\Documents\\Testing.accdb");
con.Open();
string cmdText = "Insert Into UserDetail (UsrName,Age,Address,MobileNo) Values ('" + txtName.Text.ToString().Trim() + "','" + txtAge.Text.ToString().Trim() + "','" + txtAddress.Text.ToString().Trim() + "','" + txtMobile.Text.ToString().Trim() + "')";
cmd = new OleDbCommand(cmdText, con);
cmd.ExecuteNonQuery();
con.Close();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
}

Try changing the advanced compile configuration to x86.
This is usually because you have a 64bit operating system.
in VS2008
Build -> Configuration Manager -> Active Solution Platform: -> New -> Type or select the new platform -> x86 - > OK
edit:
Try the following:
go to
C:\Windows\SysWOW64
open odbcad32.exe
if you cannot find excel in the list just click on Add and add it

You can register you assembly with RegSrv32
Because you use COM, and COM must be regsitered.
Link : http://msdn.microsoft.com/en-us/library/ms859484.aspx
RegSrv32 permit you to register your COM in register base (microsoft.ace.oledb.12.0 provider)

I have had this problem before when I have deployed an application on a User's machine that has Office 2003 installed rather than Office 2007. It sounds to me like the version of Office on your machine isn't installed correctly.
One possible work around is to change your Provider to a previous version like Microsoft.ace.oledb.4.0 and see if the same error persists.

The first thing you need to check is your build configuration of your application.
If you have built your project under x86 platform, then in order to
resolve you issue you should install the following packages on your
machine:
In order to use the 'Microsoft.ACE.OLEDB.12.0' provider you must
install the Microsoft Access Database Engine 2010 Redistributable
first, this installation is available at:
http://www.microsoft.com/download/en/details.aspx?id=13255 .
After the installation has complete, try running you application, if this
solves the issue great, if not, continue to step 2.
This next step is an unexplained workaround, which works for Office
2010, even though it is the Data Connectivity Components of Office 2007. I am not quite sure why this works, but it does and this has been proven to work in almost all cases. You need to install the 2007 Office System Driver: Data Connectivity Components, this installation is available at:
http://www.microsoft.com/download/en/confirmation.aspx?id=23734 .
After this installation is complete, try running your application, this should resolve the issue.
If you are trying to run an application built under x64 or AnyCPU
platform, I would recommend first validating that it runs as expected
under the x86 platform. In the event that it does not run under that
x86 platform, perform the steps in the first part and validate that
it runs as expected.
I did read that the MS Access drivers including the OLEDB Database
driver works only under the x86 platform and is incompatible under
the x64 or AnyCPU platform. But this appears to be untrue. I
validated my application was running when building x86, then I
installed the Access Database Engine using the passive flag.
First download the file locally You can download the installation
here: http://www.microsoft.com/en-us/download/details.aspx?id=13255
Installing using the command prompt with the '/passive' flag. In
the command prompt run the following command:
'AccessDatabaseEngine_x64.exe /passive'
After these 2 steps I managed to run my application after building in
x64 or AnyCPU build configuration. This appeared to solve my issue.
Note: The order of the steps seems to make a difference, so please follow accordingly.

How can I call SSIS programmatically from .NET?

I have an application where whenever a file is uploaded to a directory, I have to call SSIS to parse the XML file.
Can I call a SSIS directly from a .NET Windows service?

Running SSIS package programmatically.
I prefer the second method:
Start DTEXEC.EXE process. DTEXEC is command line utility for executing SSIS packages. See its command line options here: http://msdn2.microsoft.com/en-us/library/ms162810.aspx
Benefits: running package out of process gains reliability. Can be used from any programming language (including .NET 1.1 :)). Easy to pass parameters by setting variables values.
Drawbacks: Also local only. Harder to get information about package progress (but SSIS logging can give you most functionality). Some overhead on starting new process (likely minimal compared to execution time for big packages).
ASP.NET specific: Win32 CreateProcess function ignores the thread impersonation. So if you want DTEXEC to run under account different from ASP.NET process account, you should either make user enter name/password and pass it to Process.Start, or use method described in the following KB to run child process under impersonated account http://support.microsoft.com/kb/889251.

you can run your SSIS package programmatically, as follow:
using System;
using Microsoft.SqlServer.Dts.Runtime.Wrapper;
namespace ConsoleApplicationSSIS
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Loading SSIS Service...");
//Application object allows load your SSIS package
Application app = new Application();
//In order to retrieve the status (success or failure) after running SSIS Package
DTSExecResult result ;
//Specify the location of SSIS package - dtsx file
string SSISPackagePath = #"C:\Microsofts\BI\SSIS\ConsoleApplicationSSIS\IntegrationServiceScriptTask\Package.dtsx";
//Load your package
Package pckg = (Package)app.LoadPackage(SSISPackagePath,true,null);
//Execute the package and retrieve result
result = pckg.Execute();
//Print the status success or failure of your package
Console.WriteLine("{0}", result.ToString());
Console.ReadLine();
}
}
}
if you want a complete sample, go to :http://hassanboutougha.wordpress.com/2012/10/13/run-your-ssis-package-progammatically/
I explain how create a simple SSIS package and after how to call it programmatically from a console application. Don't forget to have this assembly :C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.DTSRuntimeWrap.dll to reference runtime ssis namespace
you can also pass your variables programmatically and change also source and destination connections of your ssis package

You can call SSIS programtically, execute the package and change the configuration from a .NET code using DTS runtime. Here is complete code of how you can do it.

You can call the SSIS package from your windows service. But Microsoft.SqlServer.Dts should be installed into the system where windows services are going to run. If you have installed DTS installed in that machine, directly call the SSIS package. If it is not installed then you should do the following.
Create the SSIS package
Create the job which runs the SSIS package
In your ADO.NET[resides in windows services code], Call stored
procedure which runs job[configured to run the SSIS package].
Following is an example should be called from your .NET code.
EXEC msdb.dbo.sp_start_job N'YourJobName'
Hope this helps!

Updating this pretty old question:
On SQL Server 2012 you can do this simply by creating stored procedure that will call to create_execution and set_execution_parameter
Step-by-step guide can be found here: https://blogs.msdn.microsoft.com/biblog/2013/05/07/step-by-step-of-executing-ssis-2012-package-through-stored-procedure/