VS2017, Deploy to SS2016. Package runs without any errors from VS. Project deployment to a server that previously had package deployments only - we're moving to project deployment, and DBAs said to use that.
Getting many errors like:
Get Error Information:Error: Failed to compiled scripts contained in the package. Open the package in SSIS Designer and resolve the compilation errors.
The package has absolutely no script objects. I've checked with the package explorer, and there isn't even a scripts section. To verify, I added an empty script, and then the explorer did show that section.
Other info: Package deployment is new to our DBAs. They are completely mystified by this, and other errors, like:
Get Error Information:Error: CS2001 - Source file 'C:\Windows\TEMP.NETFramework,Version=v4.0.AssemblyAttributes.cs' could not be found, CSC, 0, 0
My opinion, unexpert in SSIS as I am, is that these servers are not set up or configured properly in some way, but I am out of my depth in this, and DBAs are floundering. What might I do to get to the root of this?
I ended up side-stepping the issue by essentially recreating the package. Even XML search revealed no scripts, so the assumption was some kind of corruption. The package was recently upgraded to package-deployment - perhaps that action had a hand in the problem.
We had the same issue and isolated the problem to a Script Task (regardless of language) that existed in a Sequence Container. Placing the Script Task outside the Sequence Container, and upgrading the package to 2016 worked. The package was originally 2012 (as far as I can see) and the server side SSIS was 2016 13.2.5426.0. We were using VS 2017 as well.
For me this was happening because I was targeting the wrong database version. in your SSIS Package project go into properties and set the TargetServerVersion appropriately And then recompile the project and redeploy to sql server.
Related
I have been using XML config files for a long time. I know there are thousands of post on this. Most are not about SSIS VS2019. The ones that I found that do stop at how to setup packages. None explain what happens if it doesn't work. Upgraded all my packages from SSIS 2008 to 2019. Everything converts good except scripts. I setup my package configuration and try to run in debug it is still using the values in the package not the config file. I Also tried running them in Server Agent with the same results. Not sure where I went wrong or if its a SSIS BI issue. Please help, Thank you.
Add a existing 2008 package to my project
Had to rewrite all the scripts by copping the code. Create a new Script task\component. Paste the code in the new script close the window. Ran the project on my local DB. Everything worked.
Click on the packages background and then in the properties window open Configurations collection selected enable configurations.
Add a new configuration. Select values for Initial Catalog, Server Name, StartupDir, InputDir, ArchiveDir. Now points to Dev server and input directories.
Save the configuration.
In the package, I can now right click on the back screen and see Package Configurations as a selection. I open it and package configuration's is enabled and the file is visible.
Close the configuration put a breakpoint in the package.
Click Start, Check the variables in the locals window. They do not have the configured values.
If i let it run it updates my local db not the DEV one.
I ended up having to change the protection level to DontSaveSensitive and changing the target version to 2019. My local server is 2016 so not sure why DEV and Prod are 2019 so if I can debug on 2016 with a 2019 target I'm good with that.
Warning for anyone trying this. After doing this I received a bunch of errors when I tried to open packages with scripts. I had to open the script and close it to rebuild. Then it worked and the massage went away.
And before I forget there's this annoying little message. I just ignored it.
Please try to change SSIS Project/Package(s) ProtectionLevel setting to DontSaveSensitive.
Starting from SSIS 2012 onwards the preferred way is to use Project/Package level parameters instead of XML config files.
I have made updates to approx. 100 ssis packages which are stored in ( msdb ), which is the location I need to deploy them.
I do not have access to rdp into the server and hence I cannot run multiple dtutil commands on the server thru a bat file. I am looking for a way to deploy all the packages in some easy manner, but looking at this image, my only option is one package at a time. Without having to change the current setup what option do I possibly have?
My understanding was incorrect with regard to usage of DTUTIL.
Also I was using an older version of DTUTIL and it was throwing this error - Description: The package failed to load due to error 0xC0011008 "Error loading from XML", which made me think I will have to run my scripts locally on the server.
This post helped me .I changed it to use the latest version of DTUTIL. Mine was at c:\...\150\DTS\Binn\DTUTIL.exe & it uploaded all the packages.
I exported a package from the production server (.ispac) to my local computer and opened in SQL Server Data Tools 2015 since I need to make some changes in the work flow. This package also include a script task which I need to alter and debug.
I added a break-point in the code, the problem is that when I run the package from Data Tools, VS 2015 opens but the below error is show and VS 2015 closed immediately and therefore I an not able to debug the code.
I have been trying to solve this for a couple of hours and viewed various post but no success.
I already: Set Run64BitRuntime = False
If I remove all the breakpoints and run the package all tasks will succeed but the script task is not doing what it is intended for... (this is why I need to debug).
I am stuck and not able to fix the code!
This is a reference issue. The references (dll's) version on your production server are different from the installed dlls on your loxal computer.
Try removing all reference used inside the script task and adding them again.
useful links
https://mitchellpearson.com/2015/04/13/upgrading-script-tasks-in-ssis-target-of-invocation-on-script-task/
DTS Script Task Runtime Error: Exception has been thrown by the target of an invocation
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/78373e2b-b4ea-4ce2-9590-b624a284d538/runtime-error-exception-has-been-thrown-by-the-target-of-an-invocation-from-script-task?forum=sqlintegrationservices
"Runtime error Exception has been thrown by the target of an invocation" from Script task
I have 3 2008-style SSIS packages that I think I've done a pretty good job upgrading to the 2016 tooling. I've migrated to Project Deployment at the top level and I'm using project params - it all seems like a big improvement.
My first problem is that when I deploy to the server, it seems to succeed, but the Integration Services explorer mode in SSMS shows no packages in the place I expect to see them. The new folder is there but there's nothing in it. I was able to use 7zip to uncompress the .ispac file in the /bin folder which is being deployed and it does indeed contain the .dtsx files that I expect to see.
When I deploy, the deployment wizard lists the .ispac file Path under Source section, but not the individual packages. That's probably fine but I'll mention it in case I should see the individual packages listed.
I also notice that there's an option to "Convert Deployment Model" under the Visual Studio project's SSIS Packages section - that's separate from the "Convert to Package/Project Deployment" at the project-level. It's also separate from the "Upgrade All Packages" option that has already been done and for which there are no remaining upgradable packages.
When I run the "Convert Deployment Model" wizard and try to "Next" past the screen where the packages are listed as "Not loaded" Status, I get an error that "One or more selected packages are not ready" an an Error status on all packages with the message that The variable "$Project::ServerB" was not found in the Variables collection. The variable might not exist in the correct scope.
#[$Project::ServerB] is indeed a variable in all of the packages. And in at least one of the xml content of the package files I can see it listed in just the one place. In the editor (the Expression field of the SQL Connection Manager) where we use the variable this project parameter evaluates to the configured value just fine.
What is this "Convert Deployment Model" option anyway, separate from the "Convert to Package/Project Deployment" option? Are they the same, and the one on the "SSIS Package" folder just failing to validate the conversion (back to Package Deployment) because there are project parameters that the resulting Package Deployment mode doesn't support, hence the error?
And most importantly, why aren't my packages actually getting deployed? Is this deployment model thing just a red herring at this point? What should I be seeing?
Thanks!
I was looking in the wrong spot. In SSMS, I see them under the Database Engine side of the Object Explorer, but not under the Integration Services side. Integration Services had a folder that might have been carried over from the old deployments and seems no longer necessary. Under the database there is a new "Integration Services Catalogs" folder that now shows the projects along with the expected deployed packages.
I guess the "Convert Deployment Model" was just a distraction.
I'm just trying to understand SSIS packages a bit better and how they are deployed. Correct me I'm wrong but for any deployment, I believe there needs to be at least two files a .SSISDeploymentManifest and a .dtsx. The .SSISDeploymentManifest acts as the equivalent windows installer package which points to the .dtsx. The dtsx is the actual package of "stuff" that is referenced as an external file some how when you run the installer. When you install it, the package gets added to a list of ssis packages for that instance.
My further questions:
If i wanted to keep previous version of the same package, can I just copy the bin directories with the two above files and keep separately should I need to roll back to a previous package?
Where are these packages installed to? How does SSIS know where the packagess are?
Correct me I'm wrong but for any deployment, I believe there needs to
be at least two files a .SSISDeploymentManifest and a .dtsx. The
.SSISDeploymentManifest acts as the equivalent windows installer
package which points to the .dtsx. The dtsx is the actual package of
"stuff" that is referenced as an external file some how when you run
the installer. When you install it, the package gets added to a list
of ssis packages for that instance.
Your assumptions are mostly correct. You don't need the deployment manifest, but it can be handy. Also, you don't need to deploy to the SQL Server instance. You have the option to deploy to the file system as well. I'll explain both below.
Regarding your 1st question:
Version Control:
Make sure you're developing and checking in your dtsx packages via visual studio. Label your releases in sourcesafe or whatever version control you're using. If you are checking in and labeling, then you should be able to easily roll back to a previous version. As you mention, you also can just save a copy of your old bin directory but naturally put them in dated subfolders or something. However, this does not take the place of proper version control.
Regarding your 2nd question:
Deployment:
As the other poster states, you first have a decision to make:
a) Deploy packages to the file system
b) Deploy packages to MSDB
There are benefits to each, and everyone has their preference. I have used both, but I prefer the filesystem because it's more transparent, however there is more to maintain.
See this post for much more on this: http://blogs.conchango.com/jamiethomson/archive/2006/01/05/SSIS_3A00_-Common-folder-structure.aspx
The code is in the dtsx package. Generally,in order to make your packages portable you also abstract your connection strings and other configurable information into a config file (.dtsconfig) or environment variable (no file needed). See BOL to learn more about configuration.
The manifest file contains metadata about which dtsx and config files to install. If you open one, you'll see it's a simple readable xml file.
The manifest file makes it easy to hand over to a DBA to deploy (ask them to double-click the manifest file and follow directions, but they'll need instructions.
To me, the manifest file is more useful for deploying to SQL Server than to the file system. Really, all it does is make a copy of the dtsx and config files and puts them where you tell it. You could just as easily instruct the DBA to copy your dtsx files to a common folder on the server, and the config files to another folder on the same server.
Then when you schedule your jobs using SQL Agent, you specify that you're going to run an SSIS package that is stored on the file system and browse to where it's located. If you're using configurations, then there's a tab to specify where the config file is located.
There is so much to know about configuring/deployment/versioning of SSIS packages. But hopefully this will get you started on the right path.
When you export your DTS packages using the Import/Export Wizard in SQL Server you have the option of saving them to SQL Server or locally on the file system.
Regarding the versions of your SSIS packages, you need to query SSISDB to extract the version numbers. It's annoying this kind of info isn't shown directly in the Management Studio but, until it is, someone may find this useful:
SELECT prj.[name] as Project
,pkg.[name] as Package
,pkg.[version_major]
,pkg.[version_minor]
,pkg.[version_build]
FROM [SSISDB].[internal].[packages] as pkg
JOIN [SSISDB].[internal].[projects] as prj
ON pkg.[project_id] = prj.[project_id]
ORDER BY prj.[name]