Develop Reference

Default template for ASP.NET project in VS Community 2019 not working

So a little bit of context here, I'm completely new to C# and ASP.NET, I was following this video to help setup my project and learn the basics. I downloaded VS Community 2019 (I usually use VS Code) and tried to create a new project, the creation process is not exactly the same as the video (I assume it's a difference from Visual Studio to Visual Studio Community) but I thought that it's not different enough to be a problem.
Right after creating the project, I tried running it to check that everything is fine, but it said that there are build errors and asked if I want to run it anyway, I said yes, that's when I got this error:
I assume it's a generic error that doesn't explain what exactly went wrong, so I went to check what those build errors are, and to my surprise, there are a lot of them :
I copied some of them to look for a reason why this is happening but haven't found anything meaningful so here am I, asking here. Any ideas ?
Thank you for reading.
Edit : I recreated a project with Authentication Type "None" and it works without any problem. Retried after that with Authentication Type "Individual Accounts" and I get the build errors again. Is there something missing in my PC that I need to install or add to the project ?

I'll try to answer this as accurate as possible;
but it said that there are build errors and asked if I want to run it anyway, I said yes, that's when I got this error
This will not work. The build must succeed (at least once) in order to be able to start.
The difference might be due to a different version of visual studio, or a different template. The errors suggest you are missing some nuget packages or references.
Best you can do is find an up to date tutorial or follow the steps very precise.
Alternatively, you can start with a simple default template - those should work out of the box and you can build from there.

The snapshot you posted with the errors tells you exactly what's wrong. You are missing the packages as they don't exist in the local cache.
Try this:
Go to Menu Tools > Nuget Package Manager > Manage Nuget Packages for Solution...
On the new window that opens, verify that the Package Source combo box in the top right corner is set to "nuget.org" or "All".
That should allow Visual studio to go to the web looking for the missing packages and restore them.

Alright, finally found the problem, like Stefan said, it's a NuGet package problem.
There was no online source for the packages, so I added it like this :
Name : nuget.org
Source : https://api.nuget.org/v3/index.json
After that, you go to Project -> Manage NuGet packages -> Updates -> Select all packages and update. Then you need to create a new project (already created ones don't work and I don't exactly know why).

Visual Studio 2019 Project Dependency with Yellow Icon

I have two brand new C# .NET Standard libraries. They each have a project reference to an older .NET 3.5 Framework library. Only one of the two have a yellow icon on the reference.
Everything builds and runs fine but the triangle still exists, why?

I would hope they have a better way to report reference issues
than an unlabeled yellow icon.
Not sure if it's your real question. But you can check the Error List window to get details about why yellow icon displays on the References.
Everything builds and runs fine.
For some scenario, the build in VS can succeed although some build warnings occurs. And it will only fail when some build errors exist.
I add reference to ForTest.dll in my project, this assembly is missing or not compatible with current project, then it displays yellow icon in References. Now since in my project, it doesn't call functions from the ForTest.dll, so it won't exactly affect my build process. Then the project builds successfully and runs fine.
I have tried looking at the build log, in detailed mode, for an error
message, but cannot find anything obvious.
When building a solution with several projects, and set the log in Detailed mode, it's easier to get lost in the hundreds of build logs. Since the yellow icon only displays for one project, you can right-click the project=>rebuild to build the project, it makes the message in build log more clear.
Or just use the Error List window as I suggest above to check the warnings and errors instead of hundreds of logs during Trouble-shooting.
In addition: If you can't find any info in Error List window, then maybe the reason why the yellow icon occurs is because VS didn't load the project well. Please try right-click the project=> unload and reload the project in solution explorer. If it persists,close all vs instance and delete the .vs folder in solution directory, and restart vs.

According to Microsoft, these yellow warning signs get added for every new reference and then removed once the reference is successfully added (=assumed guilty until proven innocent). If some yellow warning remains in the solution explorer, VS knows only that that reference is missing, but doesn't know why and can therefore not display a warning message in the Error window.
Not being able to find out why there is a warning sign is very annoying. The problem was reported, but Microsoft's standard response is: "This problem seems not to be requested enough to be resolved, but if you like, you can contribute your own solution."
So if you read so far, can you please go to developercommunity.visualstudio.com: tell me what's wrong with the reference 2 and vote this issue up, telling MS they should indeed fix this.
After spending hours trying to solve a none existing error, I gave up and closed VS. When I started it again, the problem was gone.

These errors also occur when adding a NuGet package that is not compatible with the current .NET (such as .NET Framework app under .NET Standard or .NET Core, or a .NET version such as referencing .NET Framework 4.8 library from an older .NET version).
Check that the package dependency is the same as the project you're working with.

It could also mean that the third party assembly you have on your machine is not registered in the gac and hence not being found. For older projects mostly if I have to hand copy over the dlls, I will then register them with this powershell script in the directory they reside in:
gci *.dll | % { gacutil /i $_.Name }

Missing namespaces on new Visual Studio extension development installation

I need to change an existing Visual Studio 2017 extension development project. This project has everything set up just fine. However in three different computers I tried to install the necessary frameworks to build it as is and in only one of them I actually worked without issues.
I go to my Visual Studio installer and modify it by adding the workload for "Visual Studio extension development", I then open up the project and noticed a bunch of compile errors due to missing namespaces. I thought that maybe the references weren't set up properly so I went looking for what I need to add. However I can't find neither online or by browsing the libraries already in the system the ones I'm supposed to add. Even weirder is that I tried doing this in three different computers an in one of them it worked correctly without ever changing anything.
The following image is just an example of the libraries I'm missing:
I can't figure out for the life of me what am I missing here, supposedly these should be in the Visual Studio SDK that is installed with Visual Studio installer yet my system can't find it? I tried adding more workloads and components, tried uninstalling and installing again and nothing works and I can't find a single search result with this problem. Why would this work once out of three times with the exact same steps?

#magicandre1981 pretty much solved it for me. Installing that microsoft.visualstudio.editor nuget package installed almost all other dependencies as well with only other two missing that I found the reference online.
Since I actually tried it before with no success I now believe the reason that it was not working before was due to not picking the correct version like magicandre mentioned.

UWP Unable to activate windows store app error: the app didn't start

I am asking this question - and I know that there are multiple ones here in StackOverflow and other sites - because I have tried everything out there but no solution.
My problem is that this error that appears whenever I try to start the UWP app:
I tried switching between platforms (x64 and x86)
I tried to clean the solution and rebuild
I made sure that the project was on the C drive
I'm using Visual Studio 2017.

I've had this problem for a while. People suggest a lot of random workarounds (clean the project, move the project folder, repair/reinstall Visual Studio, delete configuration files, and so on).
This is the most sensible solution I've found, and the one that worked for me.
Basically, just open the Project properties, Build tab and make sure the option "Compile with .NET Native tool chain" is checked.

failed to remove Microsoft.Bcl.Build.Tasks.dll

I am having an issue with my ASP.NET Web-Api solution where my build agent cannot clean its working directories because the library Microsoft.Bcl.Build.Tasks.dll is still in use by some process so it cannot be deleted. The only things I do in my build agent are to build the solution using standard MSBuild.exe, and then I run a few unit tests using MSTest.exe.
I notice that Microsoft.Bcl.Build version 1.0.14 (the version im using) is listed as a dependency by the Microsoft.Net.Http and also by Microsoft.Bcl libraries.
My workflow in the agent is like this:
clone a git repo to the agent
build the solution using msbuild
test the solution using mstest
some time later, maybe 10 minutes, I try and clean up the current iteration
cleaning of the files fails due to the described error
My question is this:
Does anyone know why is this library in use by some process even after many minutes? Is there a common process on windows that would be using this library in the background? I would use the process manager to find why this file was in use, but these build machines are considered to be production boxes and are nearly impossible to get admin access to.
Thanks in advance for the help!

First delete any usages from processes via a program like LockHunter, then restart VS. It worked for me

If your solution contains custom msbuild targets and those same msbuild targets are in use by another csproj in the same solution, you'll run into a conflict at compile time. Effectively, you'd be trying to compile a part of the compilation process mid-compile and you'll run into these types of file lock errors. The workaround is to split your custom msbuild target project(s) out into a separate solution and build them as-needed. I think you'd need to unload & reload the project that depends on the msbuild targets anytime you rebuild them. Once or twice, I needed to restart VS.
If you didn't add any custom msbuild tasks, you can figure out what is causing the problem by looking at the installed NuGet packages. Right click on your solution and click 'Manage NuGet Packages'. Try to remove Microsoft.Bcl.Build from the Installed packages list. It should fail because something depends on it. Make note of what package depends on it. If the first suggestion didn't help, post back a comment with which packages depend on it and I'll see if I can dig up/remember where else I've seen this before.
This question has more details & links about what Microsoft.Bcl.Build is and what it's used for if you're interested: What does the Microsoft.Bcl.Build NuGet package do?

I just came across the same problem on my gitlab build server which does a git fetch before every build set.
After adding Microsoft.Bcy.Async from nuget to my project, the step after the build failed with warning: failed to remove packages/Microsoft.Bcl.Build.1.0.14/tools/Microsoft.Bcl.Build.Tasks.dll
With LockHunter I identified several msbuild.exe tasks.
With that info I found the solution here on so: https://stackoverflow.com/a/12193759/98491
Long story short: the msbuild processes are kept open to improve performance while building. This can be disabled by setting the environmentvariable MSBUILDDISABLENODEREUSE=1 or passing /nodeReuse:false to your msbuild itself.
That fixed it for me.