We have a self-hosted angent pool and I'm trying to run a pipeline with the "SSIS Build" task from Microsoft.
The MS Build task running on the same agents can find vswhere.exe just fine from what I see in the logs.
But the "SSIS Build" task is failing to find it for some reason.
I've not checked whether we have SSDT installed on the agents, could this cause the issue?
##[section]Starting: Build SSIS
==============================================================================
Task : SSIS Build
Description : Build single or multiple SSIS dtproj files in project deployment model or package deployment model.
Version : 0.2.3
Author : Microsoft Corporation
Help : https://aka.ms/AA6pzmk (Check out SSIS Catalog Configuration task if you want to configure folders, projects and environments in SSIS catalog.)
==============================================================================
----------------------------------inputs---------------------------------------
projectPath: <OurPath>.dtproj
configuration: Development
outputPath: <OurOutputPath>
-------------------------------------------------------------------------------
Checking and standardizing arguments...
Getting devenv.exe path...
ERR:No vswhere available in this machine.
##[error]No vswhere available in this machine.
##[section]Finishing: Build SSIS
It would seem that, yes, you need to install Visual Studio and SSIS designer for self-hosted agents.
Limitations and known issues
SSIS Build task relies on Visual Studio and SSIS designer, which is mandatory on build agents. Thus, to run SSIS Build task in the pipeline, you must choose vs2017-win2016 for Microsoft-hosted agents, or install Visual Studio and SSIS designer (either VS2017 + SSDT2017, or VS2019 + SSIS Projects extension) on self-hosted agents.
To build SSIS projects using any out-of-box components (including SSIS Azure feature pack, and other third-party components), those out-of-box components must be installed on the machine where the pipeline agent is running. For Microsoft-hosted agent, user can add a PowerShell Script task or Command Line Script task to download and install the components before SSIS Build task is executed. Below is the sample PowerShell script to install Azure Feature Pack
Protection level EncryptSensitiveWithPassword and EncryptAllWithPassword are not supported in SSIS Build task. Make sure all SSIS projects in codebase are not using these two protection levels, or SSIS Build task will hang and time out during execution
Related
We have an SSIS project in Visual Studio (2019 Community) that we deploy to our SQL server (2016) using project deployment. We have a couple of hundred packages and we most often deploy single packages at a time.
We had been doing most of our development in a single Azure Git master branch since these changes were separate from most of our other development. A few changes were done in a different development branch and then that single package was deployed from there. It should not have caused a problem because that single package was new and not being used in the master at all. However, when that single package was deployed it removed a couple of new packages from our live server that had been deployed from the master branch but had not been in the development branch when it was initially created.
I thought that a single package deployment only deployed that single package you selected or the few packages you selected if you chose a few of them. It seems like in addition to deploying that package it deleted packages that were on the live server but not in the dev branch that we deployed from.
We deploy from Visual Studio by right-clicking our package or packages and then choosing Deploy Package from the context menu. That process creates an .ispac file when we are deploying to our development SQL Server. That .ispac file is copied to the live server and then run directly on the live SQL server.
This should not be deploying all packages, correct? Just those highlighted? Does it remove missing packages if I only deploy a single package at a time but the packages in my project in VS and the project in the SSIS catalog do not match?
It depends!
For 2012 and 2014, the only option for deployment to the SSISDB was "Project" deployment. The entirety of the .ispac file is applied to the SSISDB - whether package1 had changed or not.
With 2016+, you have the ability to do Project or Incremental Package deployment. In the "Review" tab of the deployment wizard, in the Summary section you can see the command line indicates /ModelType:Package That is the indication it is deploying package(s) versus the whole project. See figure 5 of
https://www.sqlservercentral.com/articles/incremental-package-deployment-%E2%80%93-a-ssis-2016-feature
If you're deploying from the .ispac, then there should be a selector in the Select Source tab (not shown in referenced article) that allows you to do full or incremental deployment but the ModelType in the Review tab will identify which approach was selected. I suspect someone did a full/project deploy.
But, the nice thing about the SSISDB is that you can use SSMS to roll the project back to the previous state so no harm, no foul, no lost packages.
How can I upgrade SSIS packages created in SSIS 2014 so that they work in SSIS 2016?
I'm trying to invoke the packages using c# (Package.Execute).
My packages have custom script tasks.
I've written redirects like...
<assemblyIdentity name="Microsoft.SqlServer.ManagedDTS" culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0-13.0.0.0" newVersion="13.0.0.0"/>
But I still get the error To run a SSIS package outside of SQL Server Data Tools you must install of Integration Services or higher.
Microsoft Documentation - Understanding the Differences between Local and Remote Execution
You can only run a package outside the development environment on a
computer that has Integration Services installed. You cannot run
packages outside of SQL Server Data Tools (SSDT) on a client computer
that does not have Integration Services installed, and the terms of
your SQL Server licensing may not permit you to install Integration
Services on additional computers. SQL Server Integration Services is a
server component and is not redistributable to client computers. To
run packages from a client computer, you need to launch them in a
manner that ensures that the packages run on the server.
So, the C# code calling Package.Execute will only work on a machine with SSIS installed.
Please install SSIS on your local development machine to test this code. Or try another method to execute packages remotely.
Use SQL Server Agent to run the remote package programmatically
Use a Web service or remote component to run the remote package
programmatically
Edit: Yes, this makes it hard on developers sometimes. Microsoft wants you to pay for that SSIS license.
If you are using SSDT for Visual Studio 2017, you should be able to update the TargetServerVersion option in the properties of the SSIS project.
capture
I have some custom control flow and data flow tasks that are not showing up in the SSIS Toolbox. When I open a package in SSDT containing the custom tasks I get several errors loading the package.
Error loading MyModuleTemplate1.dtsx: Cannot create a task from XML for task "__ECT Fetch Configuration", type "MyEncryptedConfiguration, MyCustomTasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2bdffe791d57af79" due to error 0x80070057 "The parameter is incorrect.".
I've followed Russ' and Matt's replies from the following post http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5fdf9243-7e38-401e-bf4a-9251738877f9/how-to-browse-the-installed-custom-task-in-sql-server-2012-ssis-ie-custom-ssis-control-flow-task, however, the tasks still don't show.
I'm using SQL Server 2012 x64 with SSDT on Windows Server 2008 R2 x64. I have verified that the tasks are in the GAC and that the assemblies are in the appropriate SQL Server\110\DTS directories. The assemblies have been compiled as 32-bit since I kept getting a warning about targeting Any CPU while referencing 32-bit assemblies (the SQL reference assemblies).
I'm able execute the packages with the custom tasks, on the target server successfully through command line. Additionally, these tasks work fine on my development machine. I can see the tasks in the SSIS Toolbox and can open packages with the tasks without issue. My dev machine is nearly identical to the target machine except that I have full installation of Visual Studio 2010.
Am I missing something?
This problem is the result of WiX installer not properly installing the custom tasks. Below is what I did to verify this.
For test purposes I created an empty custom task and manually deployed it to the target server by copying the files and the DTS\Tasks directory. This worked so I added the .cs file of one of the tasks that was throwing errors, to the test custom task and re-deployed. I was able to see both tasks. After cleaning the solution with the original custom tasks, I manually deployed the original custom task to the target server, like the test custom tasks and was able see the tasks in the SSIS toolbox. I then uninstalled the custom tasks and deployed them to the target server using a WiX installer -- the problem resurfaced. So the problem is with the installer. My previous attempts at manually installing the custom tasks failed because I was using the assemblies installed from the WiX installer, although I don't know why.
I have a SSIS 2012 project with many packages to deploy to a server.
As written here I have to create a Deployment Utility but in my project properties there is no Deployment Utility submenu...
If I understand you correctly, you want to deploy to SSMS. To deploy the SSIS project right click your project in the 'solutions explorer' and click deploy. Follow the steps and it will be available in SSMS under 'Integration Services Catalogs'.
Hope this is what you are looking for.
I've got a number of SSIS packages spread across multiple projects in SQL Server Data Tools (formerly BIDS), which I want to deploy to the SSIS Catalog DB on my server.
When I want to deploy an entire project, I can just right-click the project and hit Deploy, to start the SSIS deployment wizard. However, there doesn't seem to be an option to do this for a single package only, without redeploying the rest of the packages in the same project.
Does anyone know if it's possible to deploy just a single package using the deployment wizard, independently from the others in the project?
This does not appear to be possible via the deployment wizard or SSDT. Similar discussion in this thread...where the original poster proposes a (terribly manual) workaround.
You might also want to get BIDSHelper from Codeplex (free tool). It contains a utility to allow you to deploy SSIS packages from BIDS. I haven't tested BIDS Helper with SSDT yet. Also you might want to grab SSIS Package Manager from Codeplex as well.
You can use SQL Server Management Studio to import a single package:
In SSMS, connect to your Integration Services instance.
Right-click the appropriate node (File System or MSDB) and select Import Package.
Set Package Location to File System.
Click the three dots next to Package Path. Browse to your SSDT project and select the .dtsx file you want to import.
Click OK. If prompted to overwrite the existing package, click Yes.