I have a customized Xaml TFS build that is building an SQL Server project and it's deploying the .dacpac file to a target database. In case of failure the build is creating a bug in TFS.
I'd like to move the "deploy" part from TFS build to the Release Management area.
It's possible to accomplish the same result with TFS Release Management?
In case of release failure to automatically create a bug in TFS.
Update 1:
I was referring to vNext templates.
Out of the box? No.
You could easily write a PowerShell script or .NET application that uses the TFS API to create a bug, then call it in a "rollback always" block within an RM release template, though.
Related
My yaml github workflow deployment build fails for actions/setup-dotnet#v1 looking for an unloaded SQL Server project. I don't understand why the build machine expects a SQL Server project file. I "Unloaded" the SQL Server project from my Visual Studio solution after creating the dacpac and before pushing. The same solution (now only .NET Core project with the unloaded SQL Server project) builds on my machine. The only reason I created the SQL Server project was for the dacpac.
C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\sdk\5.0.400\NuGet.targets(290,5): error MSB3202: The project file "D:\a\rollbase\Database-Proj\Database-Proj.sqlproj" was not found. [D:\a\rollbase\rollbase\rollbase.sln]
Build FAILED.
Deleting the sql project to produce single proj solution builds successfully on github. So somewhere a reference to the unloaded project exists if it remains visible in VS Solution Explorer. Meaning the only way I can get the runner to build my solution is to delete the sql project after producing the dacpac each time. This seems clumsy and still leaves me not understanding the error.
This fairly recent post Developer Community Issue 2020 seems to indicate the same kind of problem but opposite fail situation. Though it doesn't help to only be able to read one half of the conversation.
Has anyone got a solution for my github DOTNET_VERSION: '5.0.400 build or a better process for getting a targeted dacpac during database updates for a net core solution? I would appreciate any input.
I keeping getting the following error, after adding an annotation in one of my workflow, per below
The package 'x.dtsx' has been modified since the last build. Build the project
and try again. (Microsoft.DataTransformationServices.VsIntegration)
I tried to debug/recompile, close and open the project and I still keep getting the same issue.
Has any of you encountered this error message? Can you please share how you have resolve it?
Thanks.
Change Deployment Model
Since you are using SSIS 2017 try changing the deployment model to Package deployment model instead of Project deployment model.
The project deployment model was introduced in SQL Server 2012 Integration Services (SSIS). With this deployment model, you were not able to deploy one or more packages without deploying the whole project. SQL Server 2016 Integration Services (SSIS) introduced the package deployment model, which lets you deploy one or more packages without deploying the whole project.
Microsoft has provided a very detailed article describing the differences between both deployment model. You can check it out:
Deploy Integration Services (SSIS) Projects and Packages
Similar issue
SSIS error Failed to start project
try deleting the build file(inside the bin folder) and build it back.
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 am trying to create, test and deploy a SQL CLR (database project) using Visual Studio 2012 (update 2) and it is getting very frustrating.
The coding itself was trivial but now I cannot deploy or execute unit tests on the project. I have developed SQL CLR in VS 2010 and it was much simpler (Test.sql).
So here are my questions:
How does one set up a local SQL script to test the newly minted functions/sprocs? [I have tried adding a .sql file and marking it to be run on debug but I get error SQL71006.]
How does one deploy the project? I am deploying to SQL 2008 R2 and I know I need to use .NET 2.0 but I still have not been able to deploy anything. When I execute the generated .SQL on the target SQL Server instance, nothing happens (no errors, nothing).
This has worked so well with previous versions of Visual Studio one wonders if MSFT is perhaps now trying to discourage the generation of SQL CLR modules?
For first point, ensure that .sql file in properties has anything then Build in field Action
For second point, try to use a Publish option, where you will get a dialog box to set up database connection and other config option.
Deploy option does nothing when you work with database projects.
We have a system consisting of a winforms client, a bunch of web services, a bunch of reporting services reports and a database with a corresponding database project in VS 2010.
We use TFS as source control system and for automatic builds etc.
When our tester queues a new build from within the Build Explorer, our client and server is build and the server is deployed to the web server. Reports and database changes are not deployed automatically.
Is it possible to have the changes from the database project deployed automatically to the test database whenever a new test build is queued?
Yes.
Your build template can invoke VSDBCMD.exe to do a comparison between your database project (.dbschema) and your test database in order to generate and execute a script that will update your test database.
Here is info about VSDBCMD.
Here is the procedure to setup your build template to use VSDBCMD.