Release Management will not deploy to a SQL 2014 database - sql-server-2014

Using Microsoft's Release Management Server for Team Foundation Server 2013 v12.0.31101.0, I keep getting an error (included later). I can however successfully run the sqlpackage command from my local machine, the build server and the target SQL Server.
Steps taken:
I took the dll's and the sqlpackage.exe from C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin and copied them to a folder on my desktop
In Release Management, I created a new Tool with the command: sqlpackage.exe /Action:Publish /SourceFile:__FileName__ /TargetDatabaseName:__DatabaseName__ /TargetServerName:__ServerName__
I then added the dll's and the SqlPackage.exe from the folder I created a step earlier
Save and Close
I then created a new component which basically just wraps this tool (The Build Drop Location is a backslash to indicate the dacpac is at the root of the build folder)
I then selected the Tool I created and it filled in everything. I updated my release template to include and use the component
Putting the folder I created on any desktop, I can run the following command and it run just perfectly
sqlpackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /TargetDatabaseName:MyDatabase /TargetServerName:MyDatabaseServer
I did this from my local PC, the Build Server and the SQL Server itself, but when I use Release Management, I get the error.
Error:
An unexpected failure occurred: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception..
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacServices' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SqlSchemaModelStaticState' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.TransactSql.ScriptDom, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Update 1: I noticed on the error email from Release Management that the Target Server was my web server and not the SQL Server, even though the SQL Server was correctly named in the command. I checked the log on the web server and found the errors. I copied over my folder of dlls to the desktop and ran the script and voila, I was able to recreate the error. I checked the installed programs in Control Panel and noticed that the installed version of Transact-SQL ScriptDom was for 2012, version 11.0.2100.60. So I installed SSDT here. The installation failed because I don't have Visual Studio installed, but it still managed to install the 12.0.2000.8 versions of Transact-SQL ScriptDom and related dlls. When I ran the script again, it successfully published the database! However, when I tried to build from Release Management, I got a new error.
Publishing to database 'Logging' on server 'BYDWVCMNSQ01'.
Initializing deployment (Start)
Initializing deployment (Failed)
*** Could not deploy package.
Unable to connect to target server.
Update 2: So, I've confirmed the reason it was failing at this point was because the account that the build server was using did not have a login account to the SQL Server. I added the account and then granted it ddladmin and securityadmin privileges at the database I'm targeting. This yields a new error that I'm unable to create a new user, but at least I'm getting closer.
Final Update: I had to also grant sysadmin so the account could create a login. This allowed the deployment step in RM to succeed. This obviously is not the way I will leave it, I'll either use a publish profile or command flags to prevent the dacpac from being created with security objects and let it run with least privilege.
The issue of getting RM to deploy to SQL 2014 has been solved. The main issue was in my release template, I placed the DACPAC component inline with the rest of the build for my web server. This causes the DACPAC command to be run from the web server, and for that to work I had to install SSDT on the web server. I don't like this, and I'll probably rearrange my release template so that the web server and sql server are parallel, but nested under the same rollback.

On the server running the deploy, run procmon with a filter for the missing dll, then copy it into one of the folders it is looking in.
The correct way would be to install ssdt and the scriptdom bits (search for creating a headless ssdt build machine)

I had luck with this answer, switching from the old "SqlPackage" to the new one, I think it's some sort of confusion of related dll's:
To fix this issue, change the path to sqlpackage.exe to the new '140' version. The new path to sqlpackage.exe should be:
"%ProgramFiles(x86)%\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\SqlPackage.exe"

Related

Why do I get the error: "cannot communicate with the debug host process" when attempting to execute an SSIS package?

I create a new package in SSIS and when I try to run the package, SSIS returns the following error (displayed in a Visual Studio Error Dialog):
"Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration"
Environment: VS 2019 with newest SSIS Extension Installed. The package appears to be created correctly and the build succeeds.
The error happens even if the package is trivial "hello world" type of package.
I found no solution to this after a fairly extensive search.
Thanks to EmersioN (https://stackoverflow.com/users/707267/emersion) for the solution. The problem in this case was the selected targeted version of SQL Server. My project was configured to target "SQL Server 2017", but was connected to a server running SQL Server 2012.
If you're seeing this error, this may be the reason.
Go to the properties page of the Integration Services project that contains the affected package. In the Property Pages dialog, navigate to Configuration Properties > General. Under the property group, Deployment Target Version, in the TargetServerVersion property drop-down, select the SQL Server version that matches the one you're connected to.
I just came across this as well in VS2019 SSDT. In my case it was a working SSIS package that after going to sleep for the night, the machine woke up and wouldn't execute the same scripts. These were my steps. Hope they help you or someone else who stumbles across this.
Open each connection within the script, Test Connection and Save
Clean the solution
Rebuild the solution
My context
Working through an SSIS tutorial using SQL Server 2019 Developer (v15.0.2080.9) and VS2019 Community (v16.11.9) to create packages using SSDT (SSIS Projects v3.15).
Packages in VS have executed without issue in the past. I then upgraded my machine from Windows 10 Pro to 11. Now, when running the same - possibly any - package I get the following error:
===================================
Failed to start project (Microsoft Visual Studio)
===================================
Cannot create a debug host for the package. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.LaunchVsDebugger(Boolean isRemoteTest, IVsDebugger iVsDebugger, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.ValidateAndRunDebugger(Int32 flags, IOutputWindow outputWindow, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, ProjectItem startupProjItem, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchActivePackage(Int32 launchOptions)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.Launch(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
===================================
Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DebugEngine.DebugEngine.LaunchDtsDebugHost(Process& process, Boolean run64bit)
at Microsoft.DataTransformationServices.Project.DebugEngine.DtsProgramNode.CreateRuntimePackageInternal(IDtsHost& host, Process& process, Package& dtsPackage)
...and the package does not execute.
What was tried
I tried/checked all 3 answers posted here.
Error persists.
This VS Dev Community's post recommended upgrading the VS extension, SSIS Projects. Since I had the most recent version installed an upgrade was not applicable, so I chose the repair option from the installer.
Error persists.
I then ran a repair on the VS2019 install. This, in turn, required another repair on SSIS Projects. (I still had both installers on my machine which made this easy.)
Error persists.
This MSDN post recommended re-registering DtsDebugHost.exe, failing that, re-installing SQL Server.
I ran the DtsDebugHost.exe /regserver command.
Error persists.
My Solution
I then chose to repair my SQL Server installation instead of re-installing. This was accomplished via the SQL Server Installation Center > Maintenance > Repair option. In my case, I chose the default instance, MSSQLSERVER.
VS now runs without the error and successfully executes the package.
I couldn't say whether my solution was solely based on the repaired SQL Server instance or a combination of other things tried and my last action. So I offer the path I took in the case of the latter.
Aside: The other choices during the SQL Server repair on my system were (1) another server instance, SQLSERVER2019, and (2) "shared components". Selecting either of those may have resolved the issue as well, but I couldn't confirm that.
In Project Property, turn off Azure-Enabled as seen in the image below. Your package will execute afterwards.
I encountered this error after upgrading to Windows 11.
I referred to the post by #steveb and went straight to his solution of repairing SQL Server (SQL Server Installation Center > Maintenance > Repair), without doing any of the other steps he tried.
And that solution worked.
I'm posting this because #steveb said he was unsure if any of his previous steps had affected the ultimate solution, and in my experience they were not necessarily needed.

Could not load file or assembly MySql.data error when invoking VB.net application

I made an application in Visual Studio 2013 using VB.net that works with my MySql database.
the program compiles and runs well when invoked through visual studio. However, when I run the application in the debug folder, I get the following error.
I have.
copied the MySql.data dll to the C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MySql.Data\v4.0_4.0.0.0__b77a5c561934e089
and referenced my project to that dll. -> Error does not go away.
i set local to true for this dll in VS -> Error does not go away.
Do you know how to solve this problem?
i had a similar problem. For your application to run, you need to install the MySQL DotNet Connector msi. here is the link https://dev.mysql.com/get/Downloads/Connector-Net/mysql-connector-net-6.9.8.msi. Download and install. Your application should now run ok

Why are SSIS custom tasks not showing in SSIS Toolbox?

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.

How to fix the error 'Failed to create appdomain ssisdb.dbo[runtime].x'?

I am trying to deploy an SSIS 2012 project to an SSIS Catalog on a newly built SQL Server machine. It throws an error with the following message whilst creating the folder.
Failed to create appdomain ssisdb.dbo[runtime].6.
Trying to create the folder through SSMS alsos throws the same error, but with ssisdb.dbo[runtime].7
I enabled CLR on the instance, and now it throws the same error on ssisdb.dbo[runtime].9
I have tried running the create_folder proc - same error and SQL Server will not let me step into the proc.
How do I resolve this?
Some searches on the web reveal that there are related issues reported on Microsoft Connect website. Microsoft suggest that this could be due to a recent installation of CLR/.NET related patch, where the system reboot is pending. Try rebooting the server and then create the SSISDB catalog.
Failed to create AppDomain "master.sys[runtime].X"
Quoted from Microsoft Connect website:
Errors like:
Msg 6517, Level 16, State 1, Line 3
AppDomain "MDS.dbo [runtime] .20" Could not create.
Exception has been thrown by the target of an invocation.
come directly from .NET/CLR itself. It's usually about some inconsistency with the CLR/.NET itself. It means the CLR installation is corrupted (unlikely), or, more likely, a .NET patch was recently installed and the machine is pending a reboot.
Let us know if reboot doesn't fix the problem.
About the upgrade failure from upgrade step 677 to 678: this issue is fixed in Denali RC1.
You just have to reboot sql server services and it's done.
I had this problem for a day and after updating my windows and .NET frameworks
problem disappeared.the problem relates to .Net framework try to repair it.
I got this error in one of SQL SSIS jobs. Many jobs had failed with same error.
When I checked the recent installations, I saw that DOTNET was installed and the server hadn't completely rebooted after that. I rebooted the server and the issue was fixed.
I had a pending .NET update waiting for a restart and it interfered with by .NET web application as well as with SSIS. Restarting the server and fully installing the update fixed our issue.

Package working in visual studio but not in Job agent

I have moved my packages to another server. Now on that server when I am executing my packages on visual studio then it is working fine. But when I am deploying the same package and try to execute it both via integration services engine or SQL Job.. I am getting below error
An error occurred with the following error message: "Cannot bulk load. The file "C:\ABC\PQR\XYZ\myFile.txt" does not exist.".
Edit
Somehow that issue is resolved but now I am into one more issue
Packages installed in MSDB is working fine when I am clicking on Run Package. But when I am creating SQL Agent job for the same packages it is not working.
I have tried setting "rely on server encryption" but no luck :-(
I would suggest to check whether folder C:\ABC\PQR\XYZ\ have read permissions for an account used to run SQL Agent jobs.
If this is **C:\ABC\PQR\XYZ** mapped drive connection then use the UNC path it worked fine through the server agent.