SQL Server on a SSIS server has been upgraded to SQL 2017 from 2016
SSIS Packages are built in projects that Jenkins runs as a BIML Build (BIML Studio 2018) on a Build Server
Visual Studio Standalone has been upgraded as has the project deployment file
When we change the jenkins job to look for 2017 it thinks its looking for 2012. The environment variable in jenkins reflect what we see in the Windows PATH environment variable
When its run as 2016 the BIML Build runs fine, but the connections, script tasks, merge commands have script errors - see image link.
Error Screenshot
The scripts are built in C# and used to build each component for SSIS.
We need to know what the likely cause of the errors in SSIS are.
Related
This error just started occurring on a few developers' systems across several packages, but I can't track down a specific cause or update. We have SSIS processes created across various targets (SQL 2012 and up), but when I open them in Visual Studio 2019 this error occurs:
Error loading XXXXXXX.dtsx: There was an exception while loading Script Task from XML: System.Exception: The Script Task "ST_36ae893a14204fac97ce8ce3b4ce8ebb" uses version 16.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 can open the script task, but it's as if it's new, none of the existing code is there. Some of the older packages I can open in like Visual Studio 2017 and they work, but in Visual Studio 2019 not so much. Even some packages built in Visual Studio 2019 are doing this. Here's my dev environment:
Microsoft Visual Studio Enterprise 2019
Version 16.11.17
VisualStudio.16.Release/16.11.17+32630.194
Microsoft .NET Framework
Version 4.8.04084
SQL Server Data Tools 16.0.62205.05200
Microsoft SQL Server Data Tools
SQL Server Integration Services 16.0.948.0
Microsoft SQL Server Integration Services Designer
I've tried changing the Target server to different versions, but it seems once the issue occurs it resets the script task removing all code. I'm really confused.
Any thoughts? Thanks.
Not sure if this is a good answer, but it does seem to fix the issue. I'm using SQL Server Integration Services 16.0.948.0 (v4.3), but if I go back down to 15.0.2000.180 (v3.16) the issue seems to go away. So, it's something with version 4.0 and up. Not ideal to go backwards as we're losing some of the updates - but it gets me going again. If anyone has other suggestions, please let me know.
We are upgrading from Sqlserver 2012 to 2019 in that process we need to migrate our SSIS packages also from 2012 to 2019. We have lot of script task which uses connection string and other configurations from DtsDebugHost.exe.config It was loaded from Binn folder of Sql server installation folder by default in sql server 2012. but in sqlserver 2019 we couldn't figure out from where it is loaded to the appdata local folder. So our script task is failing because it couldn't acquire connection and couldn't resolve the libraries ( which are used in our config).
I have recently upgraded my SSIS package from 2015 to 2017.In one such package a script task is present in which after deployment if opened in visual studio 2017 an warning pop up FOUND SQL SERVER INTEGRATION SERVICES 2012 SCRIPT TASK <SCRIPT TASK NAME> REQUIRES MIGRATION. What is the exact cause of this warning? Have executed the package and it works properly through SSDT and job.
I am setting up a process to build remotely a suite of COBOL programs. A virtual machine has Visual Studio 2017 installed along with a Micro Focus COBOL Enterprise Developer 4.0 Visual Studio 2017 plugin. The programs use CICS as their UI and work with a Microsoft SQL Server backend. Opening a developer command prompt in Visual Studio and issuing a MSBuild command with the solution as the parameter successfully builds the programs. A remote build does not - the error is
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
any ideas?
You need to install the "Micro Focus Enterprise Developer Build tools" on the CI machine.
Continuous Build Database Project fails when building on TFS server. We have Visual Studio 2013 Shell (Integrated) installed. There does not appear to be a way to install SQL Server Data Tools 2013 thru' Tools > Extensions and Updates... menu.
The redacted error is below...
C:\TFSBuild\XXX\XXX\Database_CI\Sources\Database\XXX\XXX.sqlproj (126): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Has anyone experienced this? Is there a solution or work-around? Is SSDT available for VS 2013 Shell for SQL Server 2014?
I have recently installed the Visual Studio Shell (Isolated) and (Integrated) on our build server and it does not include the SQL Server tooling components. I found out that SQL Server tooling is built in to the following versions of Visual Studio (see here):
Express for Web,
Express for Windows Desktop,
Professional,
Premium, and
Ultimate
I would recommend installing at least the Professional version and then you should get the SQL Server Data Tools components that are required for building.
SQL Server Tooling is now built into the above listed versions of Visual Studio 2013 (SSDT and Visual Studio versions) and the latest March update of Visual Studio 2013 now includes SQL Server 2014 support (SQL Server Data Tools for SQL Server 2014 is available.)
To force your build to use the correct version of MSBuild set the Process - Advanced - MSBuild arguments = "/p:VisualStudioVersion=12.0" (without the quotes) as shown.
You can download SSDT for VS2012 here and that should get the database pre-reqs on your build server.
I do see mention of "Sql Server Tooling in Visual Studio 2013" on this landing page, and I think it implies these tools should be available with the shell, so if you could, check to see if you have that targets file somewhere on your build server.
Go into C:\Program Files(x86)\ and do a "dir Microsoft.Data.Tools.Schema.SqlTasks.targets /s /b" and see if something comes up.
Right now it's hard-coded to this location:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
You might want to see if the file already exists, but in another location, like in an "v12.0" folder instead of the "v11.0" subfolder.
EDIT
Actually, what's the value on line 126 of your .sqlproj?
If it says this:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Change it to read:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Then have everyone test it using diagnostic logging, then gather the logs and compare them to make sure that version is consistent so you can start phasing out the legacy bits.
I had the same issue and fixed it by downloading and installing the following
dacframework.msi
SQLDOM.MSI
SQLLS.MSI
SQLSysClrTypes.msi
from here:
https://www.microsoft.com/en-au/download/details.aspx?id=42295