I am successfully deploying an SSDT package in my VSTS release. If publishing directly from Visual Studio, there is a flag "drop_objects_not_in_source" under advanced settings. However, cannot figure out how introduce this in my CI/CD pipeline. There are a bunch of refactoring tools but none address this. So, I am stuck with object on the sql server that have been deleted.
Any suggestions?
Pass the command line argument /p:DropObjectsNotInSource=true when publishing the database or use a publish profile that contains the setting.
Related
We have a ClickOnce application we try to deploy with Azure DevOps pipelines.
We have figured the deployment process out with creating manifests and signing them.
The problem is now we want to also use the prerequisits option of ClickOnce with some custom packages.
After reading the docs we created a custom bootstrapper package and it was displayed in Visual Studio. When we publish the app with Visual Studio the custom package is added. But if we use it on the DevOps pipelin it's ignored. This makes sense because the build server doesn't know the custom package.
For example one prerequisit is the Microsoft OLE DB Driver for SQL Server.
One Idea maybe would be to not use the option "Download prerequisites from the component vendor's web site", but host the exe/msi files ourselves and link to them.
Another option could be this support URL for individual prerequisites but here I don't know how to set this to other applications.
Does somebody have an idea how custom prerequisites with ClickOnce can be added to a Azure DevOps build server/pipeline?
You could try to use Azure cli to upload the package(with its setup.bin file) to Azure DevOps artifact feeds
as universal packages type.
Create a feed first then you could use az artifacts universal publish to upload the packages.
Then you could use the "Universal packages" task in your Azure DevOps pielines to download the packages for using.
As you said, you could use visual studio run with the packages successfully. If you use VSBuild#1 task as the doc recommend in your pipelines to deploy the ClickOnce, you could add the path of the custom package in Azure DevOps, it looks like something like this:
'p:GenerateBootstrapperSdkPath=$(System.DefaultWorkingDirectory)\bootstrapper'
I hope it could help.
Recently I created a pipe line in Azure DevOps to deploy the SSIS Package automatically. I was able to complete it successfully but I'm worried weather the complete solution will be deployed every time or just the package which was modified lately. (The way we do through Visual Studio)
Or else we have any option to deploy the changes or deploy the whole.
When I say changes that means only modified object.
My Solution has multiple package but mostly I change only one package at once.
a month ago we had a solution (big one) in .net framework 4.7.2. This was building fine on azure devops pipeline.
Now we ported our solution to net5.
Everything is working in visual studio but on azure devops, the pipeline is failing.
We had to change our Microsoft.Interop.Word (and excel, and outlook) to a com reference. Because net5 is multiplatform and interop is not.
Because we removed the nuget packages and changed to com reference the pipeline is failing.
Does anyone know how to handle this specific problem?
We can't remove the interop.excel and etc from our projects because they are dependent on it.
Beneath you see the result we have.
It feels like we have tried everything to make it work again on azure devops.
have you consider self-hosted agent since you have requirement to stay the external library in this case Microsoft.Office.Interops and I don't think Microsoft Azure DevOps Pipeline agent support that currently.
With self-hosted agent, you install the PIAs and link your library/com references to the paths.
There is problem with assembly in the code, your code may be building on local environment as it is getting references for all assemblies however when you checking in the code pipelines could not fetch the assemblies through nuget package restore, if you are referencing assembly from local machine, make sure you add its nuget package reference package.config file, so nuget restore will restore the package
can you try below
Link
I'm trying to set Build Server machine in way that Build Agent is configured on it, and is targeting Azure DevOps Service (Cloud) collection, or organization as it is named like that for now. There is established connection but problem that I'm faced with is regarding workspaces.
When I try to run build definition, checkout step fails due to "Can not determine workspace..." error. As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story. I have to run the mentioned command again (new workspace is appeared in the list) and then I'm able to build that project.
Can someone point me on right way in diagnostic or tell the cause/solution if faced with this already?
According to the description and this thread which i assume is also posted by you,seems the agent in Azure DevOps is the one you used in TFS which is called as migration.
As I run the advised command
tf workspaces /collection:<collection_url>
on Build Server, I can build given project, but, when try another project, the same story.
It looks like the build definition requires a specific workspace which you managed by manual command.
What about create a new agent in Azure DevOps which is quite simple see if the problem can be resolved.
This is a different issue as I am accessing and using my visualstudio.com server. Please see the image.
I am currently working on an automation in powershell which is to create a new project in VSTS using my account. Unfortunately, I am having an error which is below.
System.Management.Automation.RemoteException: The project collection does not have a default location for creating project portal sites configured.
Either configure this location using the Team Foundation Administration Console or specify the /w
ebapplication and /relativepath arguments.
tfpt only works with TFS2015 or more older version. It does not work with VSTS and TFS2017.
You can use Rest API to create the team project via script just as you found. Or you can also consider to use the VSTS CLI: VSTS Create Project.