In the company where I work I have SSRS, SSIS and SSAS projects done in 2005 and 2008, and at this moment the company has purchased VS 2019, is it possible to migrate ssis packages from 2005 and 2008 to 2019 directly? I can't find anything on the net that is very specific in relation to this matter.
Thank you
greetings
Maybe is the answer.
If the packages were built using only standard, out of the box, tasks and components and there's no scripting involved, you can run that 2005 package with the 2019 execution engine and it'll work.
Behind the scenes, the run-time engine will create an in-memory copy of the old package and upgrade to 2019 and then run it (and then dispose of it).
When you open the package in the VS designer, then that transient upgrade becomes permanent.
With the 2016 release of the VS designer tools, MS gave us "multi-targeting" for SSIS package development. Prior to that, you needed VS 2005 to create SQL Server 2005 packages. VS 2008 or 2010 for SQL Server 2008/2008R2. VS 2012 for SQL Server 2012, etc. With 2016 though, you could now go into the project properties and specify "target 2012, 2014, 2016" etc for deployment. This continues with 2019.
Also new for 2012 is the concept of a Project deployment model. The old stuff is under the Package deployment model. It's still a valid approach and you'll likely want to remain in that model as there are differences for configuration, logging, package execute package task between them.
Script Task/Components are tricky. Some times they upgrade easy. Others you merely need to open the Task/Component and click recompile and errors sort themselves out. If someone got really clever with metadata and pipelines in a Script Component, then you're likely looking at a rewrite. The default language has switched between 2005/2008 which only offered VB.NET to C#. Both compile to IL so it doesn't matter but most folks stick with the default.
If you used custom components, then you'll need to acquire new versions built on the target set of SSIS binaries (and pray they haven't gone out of business). Register in GAC etc
You specify you purchased VS 2019, but do you have a SQL Server 2019 license to go with that? Otherwise, you're pouring new wine into old skins
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.
When creating a new Integration Services Project in Visual Studio 2013 I can select the .NET framework to target. How can I see what .NET framework is being targeted on an existing project and potentially change it?
You need to open one of the Script Tasks and click the "Edit script..." button. This will open the script on a new instance of Visual Studio with the script in its own project. There you can change the properties of that project to modify the targeted framework for that particular Script Task.
There is no .NET Framework targeting for SSIS packages. However, there IS SQL Server version targeting. Prior to Visual Studio (VS) 2015, it was a bit of a mess: you could only target a specific version of SQL Server with a specific version of Visual Studio. For example:
SQL 2008 = VS 2008
SQL 2012 = VS 2012
SQL 2014 = VS 2013
With the release of VS 2015, however, Microsoft alleviated some of the headache by introducing SQL Server targeting within VS by just right clicking on the solution, going to properties, and selecting the version of SQL Server that the SSIS package would run on. This is important because it determines what components are available to use.
Now, with that being said, there is .NET Framework targeting within script tasks/components. To read more about that, check my answer at:
SSIS Script Keeps Reverting To .Net Framework 4.5
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?
I have not seen the SQL Server 2014,just wondering is there any difference in SSIS 2012 and SSIS 2012?Any new components introduced?Any new tasks?
According to the MSDN article What's New (Integration Services), no changes have been introduced in SSIS:
SQL Server 2014 Integration Services is unchanged from the previous release.
Feature wise they are exactly the same but for some stupid reason the package format has changed and you cannot mix versions.
i.e. Packages created in VS2010/2012 can only be deployed to SQL 2012 instance (SSIS2012 runtime) and VS2013 -> SQL 2014.
If you open a VS2010/2012 solution in VS2013 it will upgrade and you cannot go back.
See this for more feedback.
http://connect.microsoft.com/SQLServer/feedbackdetail/view/944882/ssdt-bi-2014-backward-compatibility-for-ssis-2012
Edit: it seems you can deploy SSIS2012 packages to SQL2014 using Management Studio as they are automatically upgraded. The rules about Visual Studio still stand.
(I have used this - my team are mixed between 2012 and 2014)
I have a package that is developed in SSIS 2012 using Visual Studio 2010.
Is it possible to deploy/attach this package on SQL Server 2008
If it is possible, does the licence of the sql server matter
no, you cant. SSIS package are not backwards compatible.
Also it doesn't make much sense if you think about it. If it was the other way around, "maybe" it could be done because 2012 would somehow be aware of 2008 structure, but 2008 engine isn't aware of 2012 package structure.
You cannot run it with the 2008 version of dtexec and you certainly cannot deploy it into the catalog, but if you could install the minimum you need to run SSIS 2012 onto a server somewhere you could then execute the package from filesystem with the 2012 version of dtexec.
See also http://msdn.microsoft.com/en-us/library/bb522577.aspx
Best guess would be no. The engine to run the SSIS package would have to match the release level of the code. You have not been able to run any SSIS package on any release level below the developed level of the package (i.e. 2005 server will not run a 2008 package etc.)
It is not a license issue, it is an engine issue. The SSIS engine code changes with each release and therefore the code would be running in an engine that doesn't support the features or structure of the package.