Microsoft.WebApplication.targets was not found, on the build server. What's your solution?

Asked 20/10, 2010 at 18:5 Answered 28/11, 2022 at 9:27

msbuild .net-4.0 build-server targets dbproj

474

Trying to build my project on the build server gives me the following error:

Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

I solved this problem a few months ago, with installing Visual Studio 2010 on the Build Server. But now I'm setup a new server from scratch, and I want to know if there any better solution to solve this issue.

Corrosion answered 20/10, 2010 at 18:5 Comment(4)

Are Web Application Projects deprecated? I wonder what the rationale is for requiring old versions of Visual Studio in order to build them? – Uncouth 4/2, 2015 at 21:6

More to the point, do you actually deploy via the build server? e.g. I don't, I even have a seperate web installer project in the solution... and it still wants this bloody thing... answer = remove it from the proj file! easy. – Melodic 16/2, 2015 at 11:3

Strongly related: MS-Build 2017 “Microsoft.WebApplication.targets ” is missing – Pocosin 27/3, 2019 at 10:28

Fixed by replacing

<Import Project="..\Packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />

the path with $(VSToolsPath) as: <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" /> – Roanna 3/3, 2020 at 5:21

215

To answer the title of the question (but not the question about the output you're getting):

Copying the following folder from your dev machine to your build server fixes this if it's just web applications

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications

Remove x86 according to how your build breaks. If you have other project types you will probably need to copy the entire msbuild folder.

Secor answered 17/3, 2011 at 19:36 Comment(7)

This worked for m2 with a VS2012 project, after replacing v10.0 to v11.0 – Compact 5/12, 2012 at 0:25

cant we just install MSBuild tools instead of this? microsoft.com/en-us/download/confirmation.aspx?id=40760 – Torpedoman 8/12, 2014 at 17:5

Alas, installing MSBuild tools is not enough to build projects that compile fine in VisualStudio 2013 – Jolie 25/3, 2015 at 14:56

I had to copy the Web folder to v11.0 to make it work after installing VS2013, it was missing there. Could compile in VS but not via MSBUILD directly. – Wendalyn 1/12, 2015 at 9:30

@Compact I've done this to v14. But surely they'd have done some updates? – Tectrix 4/12, 2015 at 15:1

worked for VS2017. just copy C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\vXX.0\WebApplications to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications – Dissident 3/5, 2017 at 15:22

I had to create the folder v15, but it worked too. X – Balbriggan 4/2, 2020 at 10:23

127

The solution would be to install redistributable packages on build server agent. It can be accomplished multiple ways, out of which 3 are described below. Pick one that suits you best.

Use installer with UI

this is the original answer

Right now, in 2017, you can install WebApplication redists with MSBuildTools. Just go to this page that will download MSBuild 2017 Tools and while installation click Web development build tools to get these targets installed as well:

This will lead to installing missing libraries in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications by default

Use command line

disclaimer I haven't tested any of the following proposals

As @PaulHicks and @WaiHaLee suggested in comments, it can also be installed in headless mode (no ui) from CLI, that might actually be preferable way of solving the problem on remove server.

Solution A - using package manager (choco)

choco install visualstudio2017-workload-webbuildtools

Solution B - run installer in headless mode

Notice, this is the same installer that has been proposed to be used in original answer

vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools --passive

Redaredact answered 22/6, 2017 at 15:55 Comment(8)

I'm pretty surprised, that my five year old about packing libs into source control, and it modifications are still getting votes up even today, while this is correct out of the box answer. – Superannuate 16/1, 2018 at 19:57

@AndriyK Your solution is a bit different to what I suggested and I understand why somebody might prefer yours over mine... unless it's just laziness ;D – Redaredact 25/1, 2018 at 11:7

To make this more general, for future versions of Visual Studio, you can download the latest Build Tools from visualstudio.microsoft.com/downloads Scroll down the page and near the bottom expand the "Tools for Visual Studio" section, then download the "Build Tools for Visual Studio". Currently these are for VS 2017 but I assume it will be the same for future versions. By the way, if you need the path to msbuild.exe for your CI tool (eg Jenkins), for VS 2017 it will be installed at C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\msbuild.exe . – Pogge 28/6, 2018 at 22:2

Thanks for this - got it working nicely with psake with the help of the VSSetup powershell module – Butch 2/1, 2019 at 11:31

The build-server-compatible (read: command line) way of doing this is choco install visualstudio2017-workload-webbuildtools. – Glooming 28/2, 2019 at 23:41

Also note that the "Web development build tools" package, Microsoft.VisualStudio.Workload.WebBuildTools, can be installed via the command line by calling vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools. Add --passive to not need user intervention. – Pocosin 27/3, 2019 at 10:33

In AWS CodeBuild for an asp.net Framework build, the choco install worked for us. - choco feature enable -n allowGlobalConfirmation - choco install visualstudio2017-workload-webbuildtools – Morale 10/5, 2022 at 12:30

This solution is still working for VS 2022 Build Tools / Web Development Build Tools – This 14/11, 2023 at 19:54

101

Building and publishing WAPs is not supported if VS is not installed. With that said, if you really do not want to install VS then you will need to copy all the files under %ProgramFiles32%\MSBuild\Microsoft\.

You will need to install the Web Deploy Tool as well. I think that is it.

Otho answered 22/10, 2010 at 1:6 Comment(6)

Sayed - see below answer from dansomething - is your answer correct? Even installing the VS 2010 Shell Integrated package, and the .NET SDK will not correctly install Web Application project support? – Transoceanic 11/7, 2012 at 16:20

@SayedIbrahimHashimi do you have to register the DLLs with the GAC if you do a manual folder copy? – Redfish 16/8, 2013 at 20:39

And what about the Microsoft.TextTemplating.targets ? What do I have to do to get them in their folder? C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 – Simson 26/9, 2013 at 20:28

@ClarkKent, sorry I cannot speak to the TextTemplating file. I'm not familiar with those. – Otho 30/9, 2013 at 16:9

So I have to install IDE on my build server just to deploy? Microsoft is a joke right? – Tears 23/9, 2021 at 2:19

VS 2022 is install on build agent, but build fails with message 'error MSB4226: The imported project "$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" was not found.' @SayedIbrahimHashimi – Buffington 21/10, 2023 at 8:48

UPD: as of VS2017, there is workload in Build Tools that eliminates this problem completely. See @SOReader answer.

If you'd prefer not to modify anything on build server, and you still want the project to build right out of source control, it might be a good idea to put the required binaries under source control. You'll need to modify the imports section in your project file to look like this:

<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

The first line is the actual import from the new location that is relative to the solution directory. The second one is a turned-off version (Condition="false") of the original line that allows for Visual Studio to still consider your project to be a valid Web Application Project (that's the trick that VS 2010 SP1 does itself).

Don't forget to copy the C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplications to BuildTargets folder under your source control.

Superannuate answered 19/10, 2012 at 13:20 Comment(2)

This solution worked for me and was really the best option in my case. This is because I don't have access to the build server. I am using Atlassian's Elastic bamboo which spins up a new server to act as the build server. It doesn't appear at first glance that these AMIs include the Web Application targets?? That doesn't make sense to me but that is how it seems. – Statvolt 14/1, 2016 at 7:30

This is a good aproach, but this change requires each csproj file to be changed. It's tricky if you add new projects to solution. Of course it can be solved with custom project templates, but still.. Anyway, this answer pointed me to right direction. thanks! – Preshrunk 7/6, 2016 at 9:41

You can also use the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets, referencing them within your Visual Studio project(s), then change your references as Andriy K suggests.

Commutate answered 12/8, 2013 at 9:50 Comment(8)

It is impossible to use because I have to open the solution first but I cannot because of the error. – Simson 26/9, 2013 at 20:24

If there is more than one project in the solution, you should still be able to 1. open the solution - ignore that the web project doesn't load; 2. add the nuget reference; 3. take one of the approaches mentioned after that; you can manually edit the project file, or override the env.VSToolsPath variable in TeamCity. – Broadcaster 22/11, 2013 at 19:38

is this an officially released MS nuget package, or did someone just create it? – Richman 23/2, 2014 at 6:30

wonderful solution - works for different versions of VS. I needed to edit the .csproj file, YMMV – Cypripedium 26/2, 2014 at 12:12

It's not an officially released Microsoft nuget package. I know it because I created it. – Whipstitch 30/7, 2014 at 18:35

Just had a bug with that package in VS 2012, install-package command for that package would not update the packages.config... – Schriever 27/8, 2015 at 0:6

Installing this package also works on build servers that have ToolsVersion="14.0" declared in the .csproj file. Use the following Nuget to install it, get it into source control and build on the server. This also resolves syntax issues related to string interpolation in C# 6.0 using $ syntax. Install-Package MSBuild.Microsoft.VisualStudio.Web.targets – Klemens 12/8, 2016 at 0:33

@Dimi Try adding a condition like this: <Import Project="..\..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="Exists('..\..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets')" /> – Dowable 6/9, 2016 at 12:38

Based on this post here you can simply download the Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package and the targets are installed.

This avoids the need to install Visual Studio on the build server.

I have just tried this out now, and can verify that it works:

Before:

error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

After the install:

[Builds correctly]

This is a far better solution than installing Visual Studio on a build server, obviously.

Solangesolano answered 12/9, 2012 at 15:43 Comment(7)

This is the easiest and simplest solution IMO. I am using VS 2013, and I found that the Visual Studio 2013 Shell (Isolated) Redistributable was what worked (the Integrated one wouldn't install due to dependency on the Isolated one). – Protagonist 12/9, 2014 at 22:1

@MatthewSkelton - What is the meaning of build server? – Upper 18/7, 2015 at 10:31

@BountyMan - a build server is a server that undertakes or controls Continuous Integration (CI) builds of the software. Examples: Jenkins, TeamCity, CruiseControl, etc. – Solangesolano 20/7, 2015 at 15:11

Unfortunalely with VS v14.0, the way to install the package is through nuget but since my problem was that the build server did not have VS installed (only MSBuild), installing the package proved next to impossible. I spent hours fumbling with PowerShell and various half backed installation of Nuget before simply copying the folder from my PC to the server. – Stotts 13/4, 2016 at 23:46

This is the most clean solution for me. – Meaningful 2/3, 2017 at 10:16

@Stotts If the error message contains "v14" you can installed the Visual Studio 2015 Isolated Shell instead, worked for me - visualstudioextensibility.com/downloads/vs-shells (under "Download URLs"; there is a mandatory survey, enjoy!) – Heraclid 10/7, 2017 at 10:30

@Heraclid yup, exactly. Just use whatever version of msbuild you require. – Redaredact 21/7, 2018 at 11:21

The latest Windows SDK, as mentioned above, in addition to the "Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package" for Microsoft.WebApplication.targets and "Microsoft Visual Studio Team System 2008 Database Edition GDR R2" for Microsoft.Data.Schema.SqlTasks.targets should alleviate the need to install Visual Studio 2010. However, installing VS 2010 maybe actually be less overall to download and less work in the end.

Noyes answered 14/8, 2011 at 15:45 Comment(7)

FYI - If you're trying to build Sql projects on a build server w/out installing full blown VS, you're out of luck with the Team System 2008 Database Edition GDR R2 installer mentioned here. It's pre-reqs are Visual Studio Team System 2008 Database Edition SP1 (English) or Visual Studio Team System 2008 Suite SP1 (English) AND Visual Studio 2008 Service Pack 1. It seems however you can copy SqlServer.targets out of .NET Framework\v4 directory and the TeamData msbuild targets files out of \program files\msbuild\microsoft\visual studio\v10.0\ and your csprojs will build. – Maugre 4/3, 2012 at 18:26

It's definitely not the prettiest solution, but to me time is the most important. Simply copying over the MSBuild directory just lead to more issues for me. – Fissi 24/4, 2012 at 17:33

This is a really important answer because if you are an independent developer setting up a build server for a client, you don't want the client to have to maintain a Visual Studio license to be able to build their software. – Marinna 27/4, 2012 at 8:8

I only needed the VS2010 shell integrated package and EntLib 5 to get mine to build. Didn't need Team System. – Leakey 21/12, 2012 at 11:55

Installing Team Explorer will also do the trick - it includes the shell integrated package as well as TFS support, should you require such a thing. – Athiste 15/2, 2013 at 3:21

The VS 2010 Shell is no longer available at that link, "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.". – Society 11/9, 2014 at 0:33

The VS 2010 Shell installer can still be found at download.microsoft.com/download/D/7/0/… – Multiversity 19/6, 2015 at 7:24

Add dependency through NuGet & set a Build Parameter

Goal: no changes / installs necessary to the build agents

I have taken a hybrid approach to the NuGet approach by Lloyd here, which was based off of the committing binary dependencies solution by Andrik.

The reason why is I want to be able to add new build agents without having to pre-configure them with items such as this.

On a machine with Visual Studio, Open the solution; ignore that the web project fails.
In the NuGet package manager, add MSBuild.Microsoft.VisualStudio.Web.targets, as Lloyd mentioned.
This will resolve the binaries to [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
1. You can copy these to a references folder & commit,
2. Or just use them where they are at. I chose this, but I'm going to have to deal with the version number in the path later.

In Version 7, I did the following. This may not have been necessary, and based on the comments is definitely not needed now. Please see the comments below.

Next, in your TeamCity build configuration, add a build Paramenter for env.VSToolsPath and set it to the VSToolsPath folder; I used ..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath

Broadcaster answered 22/11, 2013 at 19:50 Comment(4)

no need to do step 4, if you simply replace the <Import> element in your project file with this one:

<Import Project="..\..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.12.0.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" />

– Platy 22/9, 2014 at 19:24

This should be the accepted answer... and point 4 should be deleted. – Syrup 13/2, 2019 at 14:49

@Syrup thanks, did you do the comment as knocte indicated instead? I haven't used TC in a few years, version 7 iirc. – Broadcaster 26/2, 2019 at 13:48

@Broadcaster I'm using Jenkins and not TC, so that might be why I didn't need your last point. – Syrup 26/2, 2019 at 16:17

When building on the build/CI server, turn off the import of Microsoft.WebApplication.targets altogether by specifying /p:VSToolsPath=''. This will, essentially, make the condition of the following line false:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

This is how it's done in TeamCity:

Moschatel answered 3/3, 2016 at 19:43 Comment(1)

Build targets are necessary if you're making use of Visual Studio's "Publish" mechanism. Doing this allows compilation to proceed and complete, but, it could be incomplete. – Plusch 27/10, 2016 at 14:57

If you migrate Visual Studio 2012 to 2013, then open *.csproj project file with edior.
and check 'Project' tag's ToolsVersion element.

Change its value from 4.0 to 12.0

From

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" ...

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" ...

Or If you build with msbuild then just specify VisualStudioVersion property

msbuild /p:VisualStudioVersion=12.0

Solution Source

Anthropogenesis answered 29/8, 2015 at 20:53 Comment(2)

Adding /p:VisualStudioVersion=12.0 to MSBuild Arguments in the TFS 2013 build definition (for a solution created in Visual Studio 2013) worked for me. For some reason it would look for files in a v11.0 folder without any parameter. – Geibel 20/10, 2015 at 7:46

This solution worked for me to, i used that command: msbuild /p:Platform=x86 /p:VisualStudioVersion=12.0 – Tarnation 15/6, 2016 at 7:19

It seems the new version of msbuild does not ship with Microsoft.WebApplication.targets. To fix you need to update your csproj file as so:

1) Edit the web app csproj (right click). Find the section in the csproj towards the bottom concerning build tools. It should look like so.

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

2) You need to add one VSToolsPath line below the VisualStudioVersion tag so it looks like so

<PropertyGroup>  
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <!--Add the below line to fix the project loading in VS 2017 -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  <!--End -->
</PropertyGroup>  
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />  
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />  
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

Reference link: https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/

Courbet answered 8/6, 2017 at 14:52 Comment(0)

This is all you need. Only 103MB. Don't install everything

enter image description here

Richman answered 23/2, 2014 at 8:54 Comment(1)

How I am able to put in a checkmark on that form, without installing anything? – Bulter 4/10, 2018 at 12:1

I have found this on MS connect:

Yes, you need to install Visual Studio 2010 on your build machine to build database projects. Doing so does not require an additional license of Visual Studio.

So, this is the only option that I have for now.

Corrosion answered 21/10, 2010 at 17:3 Comment(1)

The link seems to be broken. – Alphitomancy 7/4, 2015 at 15:6

Anyone coming here for Visual Studio 2017. I had the similar issue and couldn't compile the project after update to 15.6.1. I had to install MSBulild tools but still the error was there.

I was able to fix the issue by copying the v14.0 folder from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio to the same folder as v15.0 and that resolved all the errors. So now my folder structure looks like below, where both folders contain the same content.

Enceladus answered 8/3, 2018 at 20:59 Comment(0)

If you are using MSBuild, as in the case of a build server, what worked for me is:

Change the following:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

to:

<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

My Msbuild command is: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*

Hope this helps someone.

Moorer answered 21/12, 2018 at 2:10 Comment(1)

for to mention, the changes should be made to the offending .csproj, vbproj files. – Moorer 21/12, 2018 at 2:13

My solution is a mix of several answers here.

I checked the build server, and Windows7/NET4.0 SDK was already installed, so I did find the path:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets`

However, on this line:

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />

$(MSBuildExtensionsPath) expands to C:\Program Files\MSBuild which does not have the path.

Therefore what I did was to create a symlink, using this command:

mklink /J "C:\Program Files\MSBuild\Microsoft\VisualStudio" "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio"

This way the $(MSBuildExtensionsPath) expands to a valid path, and no changes are needed in the app itself, only in the build server (perhaps one could create the symlink every build, to make sure this step is not lost and is "documented").

Primalia answered 31/7, 2014 at 19:20 Comment(0)

I fixed this by adding
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"

into
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments

Mechanize answered 7/11, 2014 at 12:36 Comment(0)

I tried a bunch of solutions, but in the end this answer worked for me: https://mcmap.net/q/73123/-v11-0-webapplications-microsoft-webapplication-targets-was-not-found-when-file-actually-references-v10

It basically entails calling MSBuild from the MSBuild directory, instead of the Visual Studio directory.

I also added the MSBuild directory to my path, to make the scripts easier to code.

Gan answered 27/10, 2015 at 10:14 Comment(0)

I was having this issue building a SQL Server project on a CI/CD pipeline. In fact, I was having it locally as well, and I did not manage to solve it.

What worked for me was using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from a set of SQL scripts, which implies creating a new project. But I wanted to keep the SQL Server project, so that I could link it to the live database through SQL Server Object Explorer on Visual Studio. I took the following steps to have this up and running:

Kept my SQL Server project with the .sql database scripts.
Created a .NET Standard 2.0 class library project, making sure that the target framework was .NET Standard 2.0, as per the guidelines in the above link.

Set the contents of the .csproj as follows:

<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
  <PropertyGroup>
    <SqlServerVersion>Sql140</SqlServerVersion>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
</Project>

I have chosen Sql140 as the SQL Server version because I am using SQL Server 2019. Check this answer to find out the mapping to the version you are using.
Ignore the SQL Server project on build, so that it stops breaking locally (it does build on Visual Studio, but it fails on VS Code).
Now we just have to make sure the .sql files are inside the SDK project when it is built. I achieved that with a simple powershell routine on the CI/CD pipeline that would copy the files from the SQL Server project to the SDK project:

Copy-Item -Path "Path.To.The.Database.Project\dbo\Tables\*" -Destination (New-item -Name "dbo\Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project\")

PS: The files have to be physically in the SDK project, either in the root or on some folder, so links to the .sdk files in the SQL Server project won't work. In theory, it should be possible to copy these files with a pre-build condition, but for some obscure reason, this was not working for me. I tried also to have the .sql files on the SDK project and link them to the SQL Server project, but that would easily break the link with the SQL Server Object Explorer, so I decided to drop this as well.

Thallium answered 18/4, 2020 at 15:53 Comment(0)

In case if you're trying to deploy a project using VSTS, then issue might be connected with checking "Hosted Windows Container" option instead of "Hosted VS2017"(or 18, etc.):

Cheiron answered 4/9, 2018 at 8:51 Comment(0)

I fixed this by running the build in a docker container, specifically dotnet/framework/sdk. It includes the VS build tools.

Tears answered 23/9, 2021 at 2:29 Comment(0)

Creating a new project and copying over the settings should probably provide the best guidance in what to do. This is what it looks like on mine

  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
  </PropertyGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
  <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

Poncho answered 29/9, 2021 at 15:20 Comment(0)

In my case, It was just a Port-Block.

Kingwood answered 28/11, 2022 at 9:27 Comment(0)

-1

After installation of MSBuild tools from Microsoft, define the MSBuild path in the environment variable, so that it can be run from any path.
Edit the .csproj file in any notepad editor such as notepad++, and comment the
Check for the following elements, -->
- Make sure you use import only once, choose whichever works.
- Make sure you have the following folder exists on the drive, "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0" or whichever version is referenced by MSBuild target at "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets"
- From the command prompt, run the following command, to check

C:>msbuild "C:\\DotnetCi.sln" /p:Configuration=Release /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false

choose /p switch as appropriate, refer to enter link description here enter image description here

Zoometry answered 30/11, 2019 at 17:53 Comment(1)

Comment the what? – Aachen 23/11, 2022 at 14:23

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Use installer with UI

Use command line

Add dependency through NuGet & set a Build Parameter

Recommended topics

Hot tags