I am trying to deploy a Script component to SSIS toolbox in the Data Flow for reuse. I'm using visual studio 2010, and SQL server 2014.
I have created the script, Signed the assembly, used Gacutil.exe /i on the DLL file to add it. It now recedes in the GAC_MSIL folder under it's strong name folder.
The above procedure is the current way I'm trying to get it to work, but I have additionally tried to use SN utility to generate a strong name and add this key back into the build. Didn't work any better than the above procedure. Is it supposed to be next to impossible to add custom components to SSIS?
In my simple mind it should be just sign, build, GAC and done.
The editor for SSIS packages is tightly bound to the version of the SQL Server you're working with.
As a general reference, we have the following
VS 2005 = SQL Server 2005 {90}
VS 2008 = SQL Server 2008 & SQL Server 2008 R2 {100}
VS 2010, VS 2012 = SQL Server 2012 {110}
VS 2013 = SQL Server 2014 {120}
VS 2015 = SQL Server 2016 (once it's RTMed) {130}
Now, you could be using VS 2010 to build your custom DLL, as long as you've referenced the correct version of the SSIS DLLs, and then used SSDT-BI edition for VS 2013 to author your SSIS packages --- that's fine.
Making it work
Your current build and deploy cycle is what you need to do on your servers. That will allow SSIS to find the components when it runs.
However, you need the development experience so you need to also add that same DLL into the correct folder in your SQL Server installation. For SQL Server 2014, a custom "Script Component", or anything that lives in the data flow, would also need to be copied to
C:\Program Files\Microsoft SQL Server\120\DTS\PipelineComponents
If you've done it properly, then items automatically show up for VS 2010+. VS 2005/2008 required an additional step of explicitly adding tasks and components into the Toolbox.
If they aren't showing then you've either
built your DLL against the wrong version of the SSIS framework
using the wrong version of SSIS tools
not deployed the DLL to both the GAC and the correct DTS subfolder based upon your SQL Server version.
Clear as mud?
Related
I have created several packages in Visual Studio 2017 (SSDT) SSIS solution, they are showing target server 2017. This was on my development PC. Now, upon completion of it, I am into a challenge. The Server on which, I am moving my packages, is having Visual Studio 2008.
I can understand that downgrading may not be right away possible, but I will still be happy if I can find a way to minimize my work (i can accept package by package or so). Please note I am accessing the other server on the Remote and not able to use Ctrl+C and Ctrl+V to copy and paste package objects, so if I don't get some easy ways then have to almost write the whole package again.
Thanks for your support.
Install BimlExpress in your Visual Studio 2017 environment. Once installed, you should be able to right click on the package and with your new BimlExpress options, select Convert SSIS Packages to Biml
In the Miscellaneous section of you SSIS project, you should have a BimlScript.biml file. That is the Biml representation of an SSIS package but in a much more terse, yet user friendly syntax. This XML describes in a version independent way what the SSIS package did. Here's where it's cool as a cucumber: The Biml for a 2005 SSIS package is exact same as a 2019 package and vice versa. The Biml Engine has to "know" how to translate the package definition into version specific .dtsx but the smart folks at Varigence have already solved that problem.
Now, you need to take that generic Biml and match it up to a Visual Studio 2008/2010 installation that has the Business Intelligence Design Studio (BIDS) bits installed on it. For SQL Server 2005/2008, BIDS only came on the SQL Server installation media as that is how the product is licensed. A developer license cost 25-50 USD but you can no longer purchase it. Hopefully, the target server has BIDS installed on it.
If so, then you need to find a copy of BidsHelper or maybe the renamed product BI Developer Extensions and then you can use the Biml engine embedded in that product to emit a 2008 correct package.
If none of that works, you can try getting a free 7/14 day license for BimlStudio and the 2018 release still allows for the targeting of SSIS 2008.
Now, all of that supposes you haven't used any features in SSIS 2012+ that didn't exist in 2008 (Expression tasks, Parameters, project connection managers, etc) and I doubt a Script Task/Component is going to downgrade but the good news there is you should be able to mostly copy/paste the code into the 2008 version of the object.
I got VS 2017 15.8.1 version installed and a legacy SSIS package created and run in VS 2012 version 11.0.61219.00 Update 5. So basically two VS instances on one machine. I also installed SSDT 15.4.0 version for VS 2017. My app saves .csv file on the server, makes a call to SQL Server 2016 which invokes SSIS packages and passes the address of .csv file to it. SSIS processes the file and saves data to the database. All this is working correctly, however, instead of displaying the uploaded file on page as a link the UI throws the following error.
"Error: 2019-05-09 12:06:03.61, Code: 0xC000F427, Source:
SCR_Chk_UploadTypes, Description: To run a SSIS package outside of SQL
Server Data Tools you must install SCR_Chk_UploadTypes of Integration
Services or higher.,End Error,DTExec: The package execution returned
DTSER_FAILURE (1)."
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have some relation to SSDT and VS compatibility.
Thanks!
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have
some relation to SSDT and VS compatibility.
I imagine that is either the name of a connection manager or a Data Source in the data flow(s). Can you post a screenshot?
With respect to the error itself, please note that Microsoft requires a package to target a specific version of SQL Server.
The package that runs in VS2012 can only target SQL Server 2012.
Starting with VS2015, Microsoft introduced the concept of Server targeting. By default, when creating a package in VS2017 the targeted SQL Server will be SQL Server 2017. Have you confirmed that the SQL Server version that the package is targeting is SQL Server 2016?
For more information on targeting
The error:
There was an exception while
loading Script Task from XML: System.Exception: The Script Task
uses version 14.0 script that is
not supported in this release of Integration Services. To run the
package, use the Script Task to create a new VSTA script. In most
cases, scripts are converted automatically to use a supported version,
when you open a SQL Server Integration Services package in
%SQL_PRODUCT_SHORT_NAME% Integration Services. at
Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement
elemProj, IDTSInfoEvents events)
I'm doing exactly what it says, but it does not help.
Any solution?
This worked for me:
Install SSDT-BI for Visual Studio 2013.
Open your solution in Visual Studio 2015.
Select your SSIS Project in the Solution Explorer.
In the Project menu select Properties.
In the Property Pages dialog select Configuration Properties -> General
Under Deployment Target Version change the Target Server Version to "SQL Server 2014."
Clean and rebuild solution and redeploy.
In the revised version of the SSDT (now 14.0.61x), there is a fix.
Install new version. (SSDT For download)
Right click project > Properties > Configuration Properties > General > TargetServerVersion - Update to SQL Server 2014 > Redeploy.
Even though this question is a bit dated, I am getting the same error on the targeted server, but in a slightly different context:
created an SSIS package targeting SQL Server 2014
add a script task
deployed it to SQL Server 2014
package validation failed with "The Script Task uses version 15.0 script that is not supported in this release of Integration Services..."
I used the following environments for the development and deployment:
VS2015 Update 3
SSDT v 17.1
Deployed using SSMS v17.1
The current SSDT version 17.1 provides a support to target SQL Server 2014 - SQL Server vNext. The current version of the SSDT resolves the issue in the question by providing targeted option in the project configuration as already mentioned.
I noticed that the above SSIS project works on the targeted server if deployed with:
VS 2015 (Select SSIS Project -> Right Click -> Select Deploy)
SQL Server 2014 SSIS Deployment Wizard (probably available only if you have a local instance installed; found in the Microsoft SQL Server 2014 Windows Start Menu)
If you try to deploy it using SQL Server Management Studio v17.1 version of the SSIS Deployment Wizard the deployed package fails. The deployed script task is deployed as version 15.0 that is not supported on the SQL Server 2014.
If I deploy the same package using SSIS Deployment Wizard from Microsoft SQL Server vNext CTP2.0 Windows Start Menu, which probably got added by installing SSMS 17.1, the deployed package script task fails with same error.
In summary:
The latest SSDT v17.1 for VS2015 resolves above issue by providing targeted server configuration options
It needs to be deployed through Visual Studio 2015
It can be deployed using the targeted server version of the SSIS Deployment Wizard
If using the latest SSMS v17.1 and build-in SSIS Deployment Wizard the SSIS package Script Task will fail on the targeted server for being upgraded to SQL Server 2017 version
Maybe this is by design, but it is very confusing and caught me of guard. Just in case this is a bug I submitted a bug report.
I have several custom SSIS Tasks and Components implemented for SQL Server 2008 R2. Now we want to switch to SQL Server 2012. First I tried just to open my DTSX packages in VS 2010 and no package could be loaded. Does anybody knows what I have to change in my projects that I can use my tasks and components with SQL Server 2012.
Thanks
Assuming you've installed SQL Server 2012 and SQL Server Data Tools, you should be prompted to upgrade your solution when you open it. I'm also assuming your 2008R2 assemblies are setup for signing.
After going thru the upgrade wizard you need to do several things:
Change your custom tasks and components to target the .NET 4
Framework in each of the project properties, in the Application Tab,
under Target framework.
Update the assembly references in each of your projects to point to
the appropriate SqlServer dlls.
Build and copy your project dlls to the appropriate directory,
depending on what kind of components you are updating, i.e. Program
Files (x86)\Microsoft SQL Server\110\DTS\PiplelineComponents
Program Files (x86)\Microsoft SQL Server\110\DTS\Tasks
Register your components in the GAC.
Close Visual Studio and then reopen; open your SSIS packages and
refresh the SSIS Toolbox, by right clicking in the tool box and
selected Refresh Toolbox.
You can get more detailed info here http://msdn.microsoft.com/en-us/library/ms345161.aspx
I have an application I am writing that accepts files of various formats. Then I write code for each format (csv, excel, xml) to convert it and enter it into a SQL Server database. This is fine but I was just looking into SSIS and wondering if this would help.
The main question though is how do I run these packages within my own code? Is it easy to pass parameters? If I move this web app to another server does it depend on other components being on that server (maybe SQL Server 2012 installed)? Or is it just some DLLs I can reference from my web app?
All the demos I see are about using the SSIS tool but I am more interested in how difficult it is to call packages with parameters from my code.
The BIDS/SSDT installation includes a complete client SDK that makes it pretty simple to run SSIS packages via code.
This MSDN article explains how to load and run a package via C# in detail but the actual code boils down to:
using Microsoft.SqlServer.Dts.Runtime;
.
.
.
Application app = new Application();
Package pkg = app.LoadPackage(PKG_FILE_NAME, null);
DTSExecResult pkgResults = pkg.Execute();
The Package object has a lot of properties and methods you can look into, in particular there is a Parameters collection that allows you to pass parameters into your SSIS package before execution.
There is a very cool library called EzAPI where you can generate your own packages and call them from within C#. It gives you a lot of flexibility to generate SSIS on the fly and execute.
http://sqlsrvintegrationsrv.codeplex.com/releases/view/21238
I built a couple console apps inside this project to test some of these methods and you might find the examples useful:
https://github.com/thevinnie/SyncDatabases
Look at "BuildingAPackage" and "BuildALookupPackage"
You can programmatically build SSIS packages using C# or VB.NET and then run the packages. You can also load an existing package programmatically to execute it. I have little experience with building packages this way since most of the packages can be built easily using the following tools.
Read the article Building Packages Programmatically on MSDN for more details.
I feel that it is easier to build the packages through these IDEs depending on which version of SSIS you are targeting. You can also create initial packages through SQL Server Import and Export Wizard and save the SSIS packages to the local disk, which you can later modify according to your needs.
SSIS Version Development IDE Visual Studio Shell
------------------- ----------------------------------------------- -------------------
SSIS 2005 Business Intelligence Development Studio (BIDS) Visual Studio 2005
SSIS 2008 - 2008 R2 Business Intelligence Development Studio (BIDS) Visual Studio 2008
SSIS 2012 SQL Server Data Tools (SSDT) Visual Studio 2010
You need to reference the appropriate SSIS specific DLLs in your code to create/load SSIS packages.
However, you will need a SQL Server Integration Services license to run the package. You cannot simply reference the DLLs alone. The license is usually part of your SQL Server license, if you already have one.
Response to your comment:
We will have SQL 2012 or 2008R2 on a separate server.. So I just need to paste the needed DLLs on my web server and reference them. correct ?
The packages will execute on that server. You are just remotely invoking to execute them and you should reference the appropriate DLLs in the code within your web/other form of external application. I usually schedule the packages to run on the database servers under SQL Server Agent Job. You can try that if that is an option for you.
Package parameters are read-only from an external application. You'll need to pass them in as variables (which I have done). If you are dealing with an existing package with parameters, you may consider writing a script task that populates the parameters from the variables (which I have not done).