I have setup my .NET project in TFS Build. It builds fine locally, but I am getting this build error on the server:
The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I have no idea what it is, even googling didn't help much. My solution has some database projects. What is the issue here and how I can fix it?
You need to install the SQL Server Data Tools on all build agents. When installing a TFS Build server, people often create agents to be on that or other machines.
You can download them from the MS SQL Server Data Tools Blog or Microsoft SQL Server Data Tools, and you choose the one that corresponds to the builds that you doing (Visual Studio 2010 or Visual Studio 2012).
Note: In some cases, the error mentions the path:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets
In such cases, install SQL Server Data Tools from SQL installation, not the link above.
I have solved a similar issue by adding a new Solution Configuration that does not build the SQLPROJ. I then configured CI-CD (Azure DevOps Pipelines) to build that configuration.
In a subsequent step of the Build, I exclusively build and pack the SQLPROJ. By thisI avoid having two Solutions - one of which will only have on project; the SQL Project.
For quite a while already we use ReadyRoll.MSBuild NuGet package. Event that ReadyRoll is not ReadyRoll anymore, it is still being regularly updated and keeps working with most recent SCA addins. It contains same build extensions, and works flawlessly on our build agents without need to install anything. Biggest problem is absence of nuget support in .sqlproj files, which makes adding/updating packages bit tricky: https://documentation.red-gate.com/rr1/installing/build-components
SQL Change Automation documentation doesn't contain this section, so it's hard to say for sure how long will it stay the way it is.
For the sake of completeness, properties to add to your .sqlproj as of today:
<ReadyRollNuGetBaseFolder>$(MSBuildThisFileDirectory)..\packages</ReadyRollNuGetBaseFolder>
<ReadyRollNuGetIsRestored Condition="$([System.IO.Directory]::GetDirectories($(ReadyRollNuGetBaseFolder), 'ReadyRoll.MSBuild.*').Length) != 0">True</ReadyRollNuGetIsRestored>
<SqlChangeAutomationTargetsPath Condition="$(ReadyRollNuGetIsRestored) == 'True'">$([System.IO.Directory]::GetDirectories($(ReadyRollNuGetBaseFolder), 'ReadyRoll.MSBuild.*')[0])\tools\ReadyRoll.Data.Schema.SSDT.targets</SqlChangeAutomationTargetsPath>
If this problem occurs on Azure DevOps pipeline build agent, then please use MSBuild#1 instead of DotNetCoreCLI#2 in the pipeline YML task. It worked for me.
- task: MSBuild#1
displayName: 'Build SQL solution'
inputs:
solution: <SQL DB Solution>.sln
msbuildArchitecture: x64
msbuildArguments: '/property:DSP="Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider"'
configuration: 'release'
Related
Im following this github repo for setting up ci-cd pipeline for synapse using dacpac : https://github.com/santiagxf/synapse-cicd
In the github workflow for CI , AT BUILD DACPAC step , im getting following error :
Build FAILED.
/usr/share/azuredatastudio/resources/app/extensions/mssql/sqltoolsservice/Linux/3.0.0-
release.110/Microsoft.Data.Tools.Schema.SqlTasks.targets(1216,24): error MSB4057: The
target "BuildOnlySettings" does not exist in the project.
Im using SQL Database Projects plugin in Azure Data Studio to create the project. It by default uses .sqlproj .
Following is the dotnet details in teh github runner :
Version: 3.1.416
Commit: 8d3765c609
Runtime Environment:
OS Name: ubuntu
OS Version: 20.04
OS Platform: Linux
RID: ubuntu.20.04-x64
Base Path: /home/runner/.dotnet/sdk/3.1.416/
Host (useful for support):
Version: 3.1.22
Commit: 35fa579a30
.NET Core SDKs installed:
3.1.416 [/home/runner/.dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.22 [/home/runner/.dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.22 [/home/runner/.dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download
Microsoft (R) Build Engine version 16.7.2+b60ddb6f4 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
/usr/share/azuredatastudio/resources/app/extensions/mssql/sqltoolsservice/Linux/3.0.0-release.110/Microsoft.Data.Tools.Schema.SqlTasks.targets(1216,24): error MSB4057: The target "BuildOnlySettings" does not exist in the project.```
I have also tried using dotnet 5
Hopefully you've resolved this issue by now, but in case someone else is searching for a resolution for this issue, I believe this is probably what you're missing in your .sqlproj file:
SQLProj file example with Build Target and other properties illustrated
If you open your .sqlproj file in a text editor you'll see the properties of that file. You should have an XML element named "Project" with a property and value of "DefaultTargets="Build" It would look like this:
enter code here
I tried to add the code for my entire .sqlproj as there are some other important elements to consider when building from Azure Data Studio, especially regarding references to master database, sqlCMDVariables, etc...but I don't post here much at all and the whole "insert code here" thing is super wonky and I don't care to spend an hour trying to figure out how to use it, so...whatever. If there's enough interest I'll figure it out later, but the image will have to do.
Hopefully this helps someone.
You'll also see the (usually required) reference to Master Database for any builds, as well as the "Configuration Condition=" within the property group element. That's another important thing to have if you're building using a yml file since you need to explicitly declare your dotnet build in the CI pipeline and all that.
We currently use TFS to deploy builds to our servers in different environments such as QA, PreProd and Prod. In the current method, the build agent gets all latest from TFS, builds and publishes to whichever environment specified.
I know that you can actually just publish just to a drop folder where it creates PublishedWebsites folder, but how can you publish to servers from drop folder mentioning specific build? For example, there may be build #7, which our QA team has certified. We want to make sure that that is the build that is going to production and not latest content which might have some check ins from other team members.
Any help would be appreciated. I referred this link, but it is mentioning about overriding OutputRoot directory in publish.proj file, which is not created in the solution that we created using Visual Studio 2012.
http://www.asp.net/web-forms/tutorials/deployment/configuring-team-foundation-server-for-web-deployment/deploying-a-specific-build
You have multiple way of solving the needs.
The best option is to use LabManagement; it will take care of computing the correct Drop folder. See Using a Lab Environment for Your Application Lifecycle for details. The idea is to use the build-deploy-test workflow to deploy and run tests on a group of machines running Test Agent.
You can setup a more sophisticated process using Release Management, a new feature of TFS 2013 that you can add to 2012 as well. It offers to design your promotion process and control who authorizes deployments.
You should neither use Build or Lab Management to do deployments. Both are poor solutions for this as this is not what they were designed for.
Microsoft added a dedicated release management tool with visual studio 2013. I have configured and used it with both 2012 & 2013.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
This will be much easier than either of the other tools.
I have a publish profile set up in a VS 2012 project. When I right click on the project in VS, select Publish and click on the [Publish] button, it publishes the project to the server using the settings provided in the Publish Profile.
When I use msbuild and the command line, with the following syntax:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
Then it builds the project, and gives me a message:
Package "mvc.zip" is successfully created as a single file at the following location: file:///c:/code/mvcsite/obj/Debug/Package
And then provides info on how to deploy the package.
How can I deploy from the command line? My ultimate goal is to run the deployment through TeamCity, and am right now trying to get my command line properties correct. However, the most that I can do from the command line right now is to create the deployment package, but not to run the actual deployment. How can I do both (preferably with one statement, to duplicate what happens in VS2012 when I deploy from there)?
Since you are building the .csproj you missed one important property
/p:VisualStudioVersion=11.0
This property was introduced in MSBuild 4.5 to facilitate project sharing between VS 2010 and VS 2012. A drawback; when building the .csproj you need to specify the value for this property. When building the solution file the value can be derived from the solution file version. Read more at my blog http://sedodream.com/2013/01/06/CommandLineWebProjectPublishing.aspx.
We use TeamCity as our CI server (but I imagine this applies to any build server).
We have not installed the azure SDK on the build server and are able to build the projects which use the SDK using the workaround described here.
I now want the server to produce the packages for deployment to Azure, but when I run an MSBuild task to create the packages (as directed here) I get a strange error
error MSB4057: The target "WatGetTargetFrameworkDirectories" does not exist in the project.
which yields few useful google results.
Do I need to install the SDK? Or is this error related to something else?
WatGetTargetFrameworkDirectories is a target from AzureSDKs .targets file. Looks like your error related to Azure SDK.
Except it could be more subtle error related to not very good msbuild Azure Targets. For our own azure packaging we did need to call 2 targets "Clean;CorePublish", not just "Publish". Maybe this will also help you.
Side note: why you don't want to install AzureSDK on TeamCity BuildAgent? Build agents made exactly for that - to have frameworks you need for build. Also 1.6 and 1.7 AzureSDKs can be installed side-by-side.
I was just upgrading my project from sdk 1.3 to 1.7 and I noticed that now when I build the application the package(cspkg) is not created with the build. I have go click on publish to create a package. Is there a way to tell VS to create a package everytime a build is triggered.
Also using msbuild is there a way to do the same thing. I have multiple projects under a solution, Most of which are just libraries and then there is this azure app. Is there a way to specify a single msbuild statement with params to tell the azure app to create the package as well as build the other projects. Also when I specify debug the debug package should be created and when I specify release switch the release package should be created.
How could I do the same thing on my build server as well where I have a .proj file which specifies the sln to build. How could I mention a switch to build the package there.
Thanks,
Kunal
You can configure CSPACK command (Be sure to have CSPACK.exe launched from SDK 1.7 Path otherwise you will get some schema related errors with SDK 1.6 project) as Post Build event in your Windows Azure Application Build settings. This way when you will build, after successful build CSPACK command will run and package your application. Same way you can configure your MSBuild configuration. I just tested and it worked for me.
Visit this MSDN article on packaging a cloud service to learn more.
You can do this using msbuild as well. See the Resolution section of this question.