The target "MSDeployPublish" does not exist in the project - asp.net-web-api

I know there have been other references to this issue. But I didn't upgrade from one version of VS to another. I am currently using VS 2013. The project builds fine, and has even deployed successfully in the past. This is a brand new app. So it wasn't something inherited from another project. Where can I start looking? What can I post here that may be helpful for you guys to hopefully help me? It is a web api 2 site. I am using the publish command within VS2013.

Adding the lines below to my .csproj file seems to solve the same error for me:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
As part of trying to resolve the issue, I've also installed the MSBuild.Microsoft.VisualStudio.Web.targets Nuget Package. But I'm still not sure it was necessary in order to resolve the issue.

If you get this MSB4057 error from a WebJob project using "Publish as Azure WebJob" using Visual Studio 2013/update 4 - you may need to update the NuGet package Microsoft.Web.WebJobs.Publish
Check MyWebJob\packages.config and if the version is 1.0 you need version 1.02 or higher.
From the package manager console run
Install-Package Microsoft.Web.WebJobs.Publish -Version 1.0.2

With VS 2013 Update 4.
There seems to be issues with the template of a Webjob project so that the reference to webjobs.targets is wrong, even though you've installed the Microsoft.Web.WebJobs.Publish package.
Make sure There Import statement at the bottom of of the project is correct in terms of the path, I tested twice and found it was malformed.
<Import Project="..\..\packages\Microsoft.Web.WebJobs.Publish.1.0.2\tools\webjobs.targets" Condition="Exists('..\..\packages\Microsoft.Web.WebJobs.Publish.1.0.2\tools\webjobs.targets')" />
Also, better avoid using the below, since it binds you to a specific VS version.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

FYI, same issue on VS2019, same solution:
Install the nuget Microsoft.Web.WebJobs.Publish
Install the nuget MSBuild.Microsoft.VisualStudio.Web.targets

For those who are deploying a WebJob, this error might also be due to a missing webjob-publish-settings.json file (it should be located in the Properties folder of the WebJob project). Its structure should be e.g:
{
"$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json",
"webJobName": "MyWebJob",
"startTime": "2017-01-27T03:00:00+00:00",
"endTime": null,
"jobRecurrenceFrequency": "Hour",
"interval": 1,
"runMode": "Scheduled",
"is_singleton": true
}
(this is for an hourly scheduled job).

Having just re-installed VS 2017 (15.5.6) I ran into this with one of three WCF projects. I picked through the csprojs for all three and could find no difference between them, cutting and pasting the various imports, paths etc from the working ones didn't make any difference.
Adding the nuget package MSBuild.Microsoft.VisualStudio.Web.targets (v14.0.0.3 was the latest, i.e. VS2015) has fixed the problem...for the moment. I can't believe this has gone away for good though.

Just bumped into this exact error with VS 2015 Update 3. The latest Microsoft.Web.WebJobs.Publish was installed, and I tried unstalling and re-installing for good measure. Still didn't work but there was an error on install that I didn't see the first time around:
install.ps1 cannot be loaded because running scripts is disabled on this system.
This is something that most who have ever run a PowerShell script have run into at one time or another and easy to fix (solution is here), but the error message itself is easy to miss.

Just run the below on the project you want to publish ( and make sure your VisualStudio is running as "Administrator" )
install-package Microsoft.Web.WebJobs.Publish

In order to fix the issue for Visual Studio Enterprise 2015 Update 3, I had to install the following packages and edit the Web job's project file as follows.
STEP 01:Install Packages(Run VS as Administrator for script execution)
1. install-package **MSBuild.Microsoft.VisualStudio.Web.targets**
2. install-package **Microsoft.Web.WebJobs.Publish -Version 1.0.2**
STEP 02: Edit WebJob Project File(Unload the project from VS and Edit/Save .csproj then reload)
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

I got this error in a project with a project.json for the nuget packages.
When I removed the project.json and used the packages.config everything worked fine.
Mind that I did set the ExecutionPolicy for Windows PowerShell before I tried this, (see solution of #Jon Crowell), this might be necesary too.
If anybody finds a way to solve this with a project.json please let me know!

I hit this same problem with a project loaded in Visual Studio 2017. It was previously working on a different machine, but not when I migrated to a new one.
After trying all of the suggestions in the answers here (the question is somewhat duplicated several times on StackOverflow), I finally ran across someone elsewhere who mentioned installing the Azure SDK for VS2015.
This isn't supposed to be needed for VS2017, but it solved the problem for me. I'd previously used 2015 on my old machine but had switched to 2017. Apparently, the SDK bits still mattered.

To add to the answer by #Uri Golani, a switch to the new PackageReference way instead of with the traditional nuget that uses the packages folder, meant it looked like I could delete the packages folder. Whelp, apparently, those references in the csproj to the packages folder (which folder I had deleted) were the problem. I'm not sure how to get the right reference to something else (whatever cache the PackageReferences refer to), so for now, just re-adding a packages folder, with the Microsoft.Bcl.Build.1.0.21 and the Microsoft.Web.WebJobs.Publish.1.1.0 nuget folders seemed to fix this.

Related

VS 2017 15.3 Yellow Triangles on References

This morning I upgraded to VS 2017 15.3 and now am getting yellow triangles for most of my references. The project runs fine (build is good in CLI and VS and restore has been run multiple times) that I can tell (and even better on dotnetcore 2.0 actually) but these remain. Has anyone else had this happen or have a suggestion? Thanks.
Link to project.assets.json file --> https://www.dropbox.com/s/c85yuyjiu4pnget/project.assets?dl=0
Also issue of greyed out usings and red references although everything builds and runs fine.
Update: VisualStudio twitter account responded to me to note that this is a bug and they are working on a fix for the future on this....
I have two responses to my post:
1) The using issue noted with things greyed out was actually a ReSharper issue. If you upgrade to VS 2017 15.3 and use R# make sure you update it as well to 2017.2.
2) The Yellow triangles issue is being looked at by the Visual Studio team but honestly I believe it to be linked to warnings in the build that those references are being coerced to either lower dependencies (ie Newtonsoft at different levels) or previews. The quickly evolving .NET 2.0 world may have exacerbated this issue. Yellow triangles have traditionally meant missing but check your warnings to see if that is related and then review the dependency chain. I will update this answer once I hear back from VS team (shout out to them and Damian Edwards + Scott Hanselman for helping me with this on Twitter).
I was experiencing the yellow triangle on references issue after updating the projects in my (.NET 4.6.1) solution to the new .NET Standard .csproj format that comes with VS2017. The references I was getting warnings for were ProjectReference type (although it seemed to spill over into PackageReference for common packages in the projects in question).
I did not have any build warnings and there was nothing in the verbose build output to indicate what the cause could be.
I could follow all warnings back to a single project in my solution. I was able to solve by removing that project from my solution and then adding it back and re-adding only the necessary project references.
It seems the issue was related to unnecessary project references (or possibly circular) caused by the new transitive dependencies support. After removing the project and adding it back with only the minimum ProjectReferences and relying on transitive dependencies support to propagate the dependency, the warnings all disappeared.
This also solved an issue where the project in question was failing compilation during a command line msbuild initiated build on my CI server which only has VS2017 build tools installed (not the full IDE).
I had the same issue, some of the references were marked with the yellow triangle. However, I was able to build and run my project.
I managed to remove these warning by following steps from this answer:
.Net 2015 References with yellow triangle for Nuget packages on portable libraries
I turned on tracing for Visual Studio, I had next warnings in log files for all uncorrectly loaded references:
Encountered conflict between 'Reference:Microsoft.Win32.Primitives, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll'. Choosing 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
To be precise, I did next steps:
Removed error condition from my .csproj file
Removed <Private>true</Private> parameter for not-loaded references in .csproj file
Deleted not-loaded packages from \lib and \ref folders in corresponding MSBuild folder.
Deleted packages from \packages folder in solution.
Restored nuget packages.
I'm not sure all these steps are necessary, but it worked for me.
You could check my answer on relative topic here: https://stackoverflow.com/a/59704420/7969733
Just for documentation purpose for new person with this issue try
this and you will rememberme :D
If you go to: Tools > NuGet Administrator > Configurations. and you
have "Allow nuget...." and "automatically check...." cheked.
The only thing than you have to do is click con the button "Clear
All NuGet Cache(s)"
That's it, you don't have to edit manual thinks than can be dangerous,
believe me, I use to need to done some of the steps than describe here
a lot of time, and try more than 5 steps of the official Microsoft
documentation for that issue you could check it here:
https://learn.microsoft.com/nuget/consume-packages/package-restore#restore-packages-automatically-using-visual-studio
But just cleaning the cache solve all the problems
To "Clear All NuGet Cache(s)" in Visual Studio 2019
Tools->NuGet Package Manager->Package Manager Setting
Mismatched Windows SDK Version between the referencing project and the references will cause it. In the vcxproj file it is "<WindowsTargetPlatformVersion>SDK Version</WindowsTargetPlatformVersion>"
I was upgrading from VS2012 to VS2017. Everything was good, then I upgraded to a new version of libtomcrypt and libtommath. Rather than tweak my existing projects, I up-converted the projects from the distributions from VS2008 -> VS2012 -> VS2017. In the process, I picked up Windows SDK Version 10.0.17763.0 in both the new projects. However, all of the projects that referenced those were 8.1, and thus the warning.
I know that this was ready to solve it, and one of my answers was ready to say something about that, but, maybe some of you present the same error and none of this solution listed here solves the problem... I don't know why this problem comes with the global installation of .net 6, but, if you present this issue again, you need to go to
C:\Users\YourUsername.nuget
And delete all the content, don't be afraid, that's a cache generator than will be created again if is need it.
I had a similar issue with visual studio 2017. And discovered that, if when I changed the dependency settings of the package I wanted to install (from lowest dependency to highest) everything worked fine.
Today faced the same issue with an imported project.
FAILED ATTEMPTS: Tried updating nougat packages, checking improper imports and everything imaginable. No help.
SOLUTION: At last just tried building the solution and it worked!
PS: Try building the project first. If it does not work then go for solution hunting.

TypeScript VsTsc error in Visual Studio 2017

I'm testing migration from VS 2015 to VS 2017 for a .NET Core / TypeScript project.
The build fails in VS 2017 with this error in Microsoft.TypeScript.targets:
MSB4064 The "PreferredUILang" parameter is not supported by the "VsTsc" task. Verify the parameter exists on the task, and it is a settable public instance property.
The version of TypeScript in VS 2017 is 2.1.5, however, I have already installed the 2.2.1 SDK for Visual Studio 2015.
I've also noted that there is no 2.2+ SDK release for Visual Studio 2017 yet.
Could this be causing conflicts? Is this something I can resolve now or do I need to wait for an update to the TypeScript SDK for VS 2017 to reach 2.2.1+?
Any help in this area appreciated!
This might be a bit of crude solution to the problem but we simply went through the "Microsoft.TypeScript.targets" file and removed PreferredUILang="$(PreferredUILang)" from any <VsTsc ... > nodes, we had a look into the Typescript task dll and it seems that it does not have a PreferredUILang property.
It is possible that the task once upon a time did have such a property but was removed and Microsoft have forgotten to update the targets file, I'm not sure but this seems to be working for us at least.
Please make sure you backup your "Microsoft.TypeScript.targets" file before editing.
I have same problem here in VS2015 Update 3 and I also fixed the Microsoft.TypeScript.targets, as suggested by ginja, but as I don't like to hack the nuget packages I went deeper in the issue.
The real problem is that when you add/upgrade the typescript nuget package, you have to manually remove the imports to the machine-wide targets and props. having both leads to unknown load order or targets/tasks, which would manifest in such errors.
So the approach I used is:
Uninstall from the project the nuget packages "Microsoft.TypeScript.Compiler" and Microsoft.Typescript.MSBuild"
Close VS (to guarantee the real clean of such package)
Edit you .csproj file commenting out the imports to the machine-wide targets and props: (all <Import Project="$(MSBuildExtensionsPath32)\Microsoft\...
Restart VS, open the project and add again the nuget packages for Typescript. This point correctly updates your .csproj with the correct imports and configuration of the TypeScript compiler.
Just for a clean safe: restart VS.
removing following lines from CSPROJ solved problem for me
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets')" />
to edit csproj file
Right click the project in Solution Explorer.
Select "Unload project"
Project is now unloaded.
Right click the project again and select
"Edit blah.csproj"
Make your changes and save them.

Typescript build failure

I'm currently having two projects with typescript 1.1 that are opened in visual studio 2013 with typescript 1.8 installed. VS asks to upgrade which I did but now I get the following error:
Unknown compiler option 'listemittedfiles'.
Anyone has had the same?
It seems inside the project we had this line hardcoded
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" />
That way even though it was upgraded to 1.8 it still tried to use w/e was installed in that folder.
(This is a very old project that needs maintenance...)
Next to that I've removed the hardcoded path in the Path system environment variables so that tsc.exe now points to the NPM version.
If the above answer doesn't work for you, I suggest to take a look to this other answer which addressed that same issue on Visual Studio 2015 Update 3 and above:
(to summarize it, installing TypeScript 2.0 from this official link might fix the messed-up MSBuild cfg and solve the issue).

Visual Studio 2012 The project type is not supported

I am having trouble with a web application project that was originally created in VS 2010 and then imported by someone else within our team of 3 developers. The solution is a pretty complex MVC4 project with multiple projects.
When I try and open the solution, I get the project not supported message for the MVC4 web application. All the other projects are class libraries and they load without any problem.
I am the only one of the three who gets this error. Even more strangely, if I share my solution folder the other devs can open my solution without any problem.
I have tried repairing the VS 2012 installation, but still get the error.
I could try doing an uninstall / reinstall, but I am really curious as to why this is happening.
I have looked in the CSPROJ file and found the VisualStudioVersion attribute set to 10.0. Surely this cannot be right?
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
If anyone has any explanation for why this problem is occurring, I'd love to hear it!
Thanks
I had the same issue of not being able to open a MVC 4 csproj solution in Visual Studio 2012 for the first time.
I had 2 GUID's inside my ProjectTypeGuids element, and my plan was to take one out at a time. When I removed the GUID that corresponded to a Test Project Type, {3AC096D0-A1C2-E12C-1390-A8335801FDAB}, the project loaded normally.
You may not need to do the nuclear option of removing them all to fix the issue, as it could be related to Test Projects.
Also, it appears that this has happened with previous releases of both Visual Studio and MVC, as there was another Stack Question here.
while removing the GUIDs allows the project to load, for my MVC 4 project, I had to uninstall and re-install Visual Studio 2012.
I tried to avoid this by adding all the updates, service packs, and extra components, but none let VS understand that .NET 4.5 / MVC 4 was installed on my machine. In my rush, I lost track of exactly which updates I installed, otherwise I would list them.
The uninstall + re-install allowed VS to understand that .NET 4.5 and MVC 4 were installed on my machine. Project loads, builds, and runs now.
HTH

The referenced component 'System' could not be found. (or any other component for that matter)

Issue: Just started today, all references to any assembly outside of the solution fail to resolve, with The referenced component 'SomeComponent' could not be found. when trying to build. This happens for both 3rd party components (all 15 or so of them) as well as all .NET Framework assemblies - basically anything that isn't another project in the same solution.
Trying to load some other solutions produced the same issue. Creating a new WinForms project worked without a problem, however. (Scratch that, it worked before reinstalling VS, now that doesn't work either. I created a new WinForms app as well as a WPF app, and the designer can't load the assemblies either. I tried targetting 3.5 and 2.0 and no luck.)
Things I've tried:
Repair Visual Studio installation
Rebooting computer
Started VS with /resetsettings flag
System Restore to 2 days ago when it was known to be working
Uninstalling VS and reinstalling
Fresh checkout from SVN
Does anyone have any experience with this and know of a way to get this working again? My strongest Google-fu has failed me, so I'm asking here. Can mark community wiki if requested.
Update:
I tried "upgrading" Windows (to the same version) since I didn't see a repair option for Vista and it's still a no-go. I reinstalled everything that seemed relevant. So far, it's looking like I'm just gonna have to back up and reformat I guess unless a solution comes up sometime before tomorrow.
Update2:
I just backed up data and reformatted, so I'm no longer able to verify any ideas that I haven't tried yet, so I'll just leave the bounty to expire on its own to the top voted answer and as a reference to anyone else who may have this problem later.
I had the same problem. It turns out that something was wrong with NuGet. I removed the following part of the *.csproj-File (opened in a text editor). This has solved the issue for me:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
In my case, the solution was completely different. It looked like it was an issue with NuGet paths (caused by my moving the project to a different solution and then back again.
I edited the .csproj and removed all references to NuGet and associated packages. I also removed the packages folder from the solution folder.
The system components then magically reappeared.
Suggested next debug step: review Project Designer: References -> Reference Paths to verify that the paths to your system and third-party components appear correctly. (Watch out for things that can slip past the old Mark I Eyeball like drive letters.)
Try running VS after turing on Assembly load logging with fuslogvw. You'll be able to see additional errors captured by the runtime when it tries to locate and load the assemblies.
In Vista, you'll have to run fuslogvw as an administrator and somtimes specify an explicit path to save the logs.
You can also try debugging Visual Studio by attaching to it from another instance, or with the basic debugger included with the .NET SDK.
I had this similar issue not too long ago.
I found that the issue was caused by git not properly creating .exe's when jumping from branch to branch(we have nuget.exe in a path and it was getting deleted/added when jumping branches). When you would try to run nuget, windows would throw a fit over the exe.
After reseting the branch many times, I finaly got the exe to run properly. Then I noticed that the security on all the directories in the repo had been reset, so I had to deal with that.
After all of that, visual studio then started to play nice.
Hoped this helps someone!
It may also be a problem with references of other projects in the same solution. I only wanted to build one project, but got this message about references in another project. Although the problem in the other project was correct, I think the message was not correct:
I did not expect the message about another project (the other project was no dependency, so it did not 'need' to be built)
I could not 'interpret' it, because it did not mention the project it was about).
Well, if you click on the error, in VS 2012 RC, and then debug it, the error is gone...
I know that this is an old question but it is still happening in the latest version of Visual Studio (2015). I fixed it in a different way that might not have been available back when the question was asked. Basically, it is related to the fact that VS can't find the .Net Library package. To fix in the latest version of Visual Studio (2015):
Right Click on your solution in the Solution Manager. Choose "Manage NuGet Packages for Solution..."
in the NuGet Window, go to "Installed".
If you have something related to Microsoft.Net such as "Microsoft.NetCore.UniversalWindowsPlatform", remember the name and uninstall the package.
Now go to the browse tab and find the package and install it again. Don't forget to select the correct needed project.
Everything should be ok now.
I hope this helps somebody!
I hate to say it, but it sounds like the system is pretty borked. There has to be a point when it is quicker to reinstall the OS than it is to continue trying to fix the current install.
I just hope you take this in the right spirit... sorry.
Shot in the dark here, but I've run into the same (similar) problem. The issue I ran into was related to having a 64bit machine and running a project that had a mixture of 64bit and 32bit 3rd party dll's. The solution was to ensure I had the correct bits (32v64) and then to have the project build in 32 bit mode: project properties > build > platform target: x86.
Another time this occurred I had to remove all the 64bit dll's and reinstall with the 32bit dll's
HTH's
.nuget folder was missing. add the .nuget folder with nuget files (usually 3 files). open the solution and no warnings on references. My submodule has nuget references and when I pulled the latest version, the solution needs .nuget folder in the project folder.
i.e.
project
/.nuget
/submodule
/.nuget
Visual Studio was unable to find any of my references.
What i did, and following some solutions above, was:
Right click solution entry in Solution Manager window;
In the newly opened NuGet window go to installed, select all entries and update.
The problem gets solved!
Check your output with ILDASM to make sure the references are showing up correctly -- compare them to an assembly that works, and see if anything jumps out at you.
I once encountered a problem, which is in the *.csproj file. It defines an Error node in the Target node, that if one reference/nuget-library doesn't exist, it throws the error while building. The problem is VS do not show correct status for other libraries, thus all the referenced libraries looks like non-loaded, that the local file path cannot be found in the property window.
Here is a sample.
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. xxx.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
<Error Condition="!Exists('..\packages\NOT-Exist.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NOT-Exist.targets'))" />
</Target>
...

Resources