I'm investigating how to do Continuous Integration with SSIS projects.
So far I've found out that it can be done by building the solution with devenv.exe or MSBuild.exe.
If its configured, Visual Studio can validate SSIS packages before they are run, to verify if the metadata in SSIS package is in sync with the source.
As far as I know, VS will only show validation errors/warnings when the SSIS package is open, but not when building the project.
Is it possible to have devenv.exe or MSBuild.exe also validate the packages during build?
I am using SSDT 2015 preview.
Dtexec.exe has a /Validate option which stops excecution after the validate phase.
this could easily be scripted into your process.
Related
I'm fairly new to Visual Studio and SSIS and was wondering if someone could just clear up for me how Visual Studio SSIS Projects and Visual Studio in general handle Add-In Extension and Package Deployment.
The Scenario: I am currently developing and creating a Visual Studio SSIS Package on my local machine.I need to use an extension from the Tools > Extensions and Updates which just links me to a webpage.I need to install this and use it to make a package which I will deploy to the Integration Services Catalog on a SQL Server 2014 that does not have Visual Studio installed. When I deploy this project as a package will the things the extension did be baked into the package or is it like references where I will need to install the extension on the server that will be running the package via SQL Agent Job. Thanks, any help is appreciated.
When you deploy a package to the catalog, all libraries/extensions (eg.azure connection etc) are deployed along-with, so no special treatment is needed. But many a times you will need to ensure your frameworks( eg. .net 4.0 etc) exist for the extension to be executed on the integration services server you are deploying to.
In some cases you have to register the dlls using GACUtil, to the integration services server. Your custom tool installation instructions will specify that.
We have two packages as part of one job. We copied these same packages from one SQL Server Integration Services Catalog SSISDB folder to another SQL Server in the same Integration Services Catalog SSISDB folder (same namespace). When running this job on the new server with the packages copied, the job runs but fails and also does not produce an error message (we have any error message logged).
When building and deploying from Visual Studio these same two packages to the same SSISDB folder and then running the job, the job runs as expected.
When deploying via the .ispac file, the script tasks we have error out with with
ScriptTaskName: There was an exception while loading ScriptTask from XML:
System.Exception: The Script Task "ST_0001a..." uses version 15.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
MicrosoftSqlServer.Dts.Tasks.ScriptTaskScriptTaskLoadFromXML(XmlElement
elemProj, IDTSInfoEvents events)
How come only the build and deploy way makes the packages work as intended?
There are several possible causes of such error.
First - you should update your version of SSDT from MS to the latest, set up correct target SQL Server version in the project properties and rebuild the packages. It might be the case when this property is reset to SQL vNext.
There are statements that your version of SSDT contained errors leading to this error.
Second - by some reason when deploying .ispac from SSMS or by clicking it at File Explorer, SSMS implicitely upgrades the project and packages in it to its own version. Detailed report on this behavior. I suspect you have SSMS 2017 and it performs such implicit upgrade of Script tasks to version 15.
If you want to deploy package by Support Team without using SSMS, here is the way. Use IsDeploymentWizard - Microsoft utility to manage package and project deployment. It has both GUI and command-line parameters to handle the deployment.
Here is a sample from one of projects:
isdeploymentwizard /S /SP:"D:\Project\Proj.ispac" /DS:"myserver\instance" /DP:"SSISDB/ProjectFolder"
Ensure that IsDeploymentWizard is started from SQL bin directory %ProgramFiles%\Microsoft SQL Server\130\DTS\Binn, not from SSMS.
I have some tests in one solution which run some SSIS packages from another solution. I use Visual Studio 2015. SSIS packages are made using SQL Server 2012. The problem is that when I run SSIS package from it's solution (on my machine) then everything works fine but when I try to run the same package via tests from another solution I get the message:
to run ssis package outside of sql server data tools you must install Derived Column of Integration Service or higher
The tests works fine in TeamCity on server. I cannot run them because of that message only locally.
Can anybody help me with this?
Status:
I have a TFS 2013 installation on a dedicated machine and I modified the build template so that it just runs a batch file (no Visual Studio project required), which we commit on our repository. While this batch file runs, it builds our code and runs some custom test suites, which the test output are multiple JUnit XML files.
I already found a way on how I can convert the JUnit XML to .trx files via batch, but now I'm stuck when it comes to publishing those results to TFS.
I found out that there are multiple ways to do that, but unfortunately no way is possible on our build agent right now.
I tried:
Use the TfsPublisher, which is described here - I can't do that because we don't have Visual Studio on our build agent machine installed
Use MSTest.exe as described here, but I can't do that either because -again- we don't have Visual Studio on our build agent machine installed
Question:
So is there an alternative way which I haven't found yet to publish the .trx files to TFS? There must be a solution. I can't be the first person who tries to accomplish that.
Instead of installing all of Visual Studio, you could install the Test Agents for Visual Studio which is much smaller:
https://www.microsoft.com/en-gb/download/details.aspx?id=40750
Greets.
I've developed some SSIS packages that I want to load up and execute in C# code. The C# code is deployed on our application machine.
I've referenced the SQLServer.ManagedDTS DLL in my C# project.
I tried gac'ing that DLL on our staging application box, which incidentally also seemed to require gac'ing the SQLServer.DTSRuntimeWrap DLL as well.
The code to execute the package is like so
Runtime.Package package = new Runtime.Application().LoadPackage(ssisPackageFilePath, null);
package.Variables["FilePath"].Value = sourceFilePath;
//Excute Package to insert data from source csv file into a SQL table
Runtime.DTSExecResult results = package.Execute();
When I try to run the process I get the following error
An Integration Services class cannot be found.
Make sure that Integration Services is correctly installed on the computer that is running the application.
Also, make sure that the 64-bit version of Integration Services is installed if you are running a 64-bit application
I figured I should be able to simply gac (Install) the one DLL I used to develop the code that executes an SSIS dtsx package file.
I developed the package in a Visual studio 2008 BIDS project which results in a dtsx file.
I referenced the SqlServer.ManagedDTS DLL in a visual studio 2010 project to execute the dtsx file from code.
Tested and debugged locally with success.
What do I need to do to setup my application box in order for my code to be able to execute an SSIS package?
I'm hoping I'm not limited to only being able to execute packages from code on a box that has an instance of SQL server or IntegrationServices installed; which may mean the need for another license.
Do I need to install Integration Services on my app box?
Yes, you need to install Integration Services to run the package on a server. Just deploying DLLs into GAC won't help in executing a package.
Here is the MSDN link that describes about Running an SSIS Package Programmatically on a Remote Computer.
You need to have at least one server with Integration Services installed to be able to do what the MSDN article describes.