We Keep Coding

Azure Functions(.net core 3+) - Getting "Entry point was not found" error when trying to access HttpRequest.Query

I started encountering this issue about 3 days ago after an update that I randomly clicked on when I was in Visual Studio Code. Whenever I try to access HttpRequest.Query from the Microsoft.AspNetCore.Http namespace, I get an the following error message: "Entry Point was not found".
I have not been unable to fix this and this has interrupted my ability to work. I've talked this over with my teammates, and they are not encountering this issue at all.
I've tried pretty much everything I could google and think of.
Auto Generating Bindings
Deleted and re installed every Nuget Package at C:\Users{username}.nuget\packages
Deleting and reinstalling everything about Visual Studio and Visual Studio Code
Using the most recent versions of Microsoft.NET.Sdk.Functions
Deleting the bin and obj folders of my project
Removing unused references in my project
At this point, I'm not even sure what's really wrong any more. I found a post with my EXACT SAME issue, but the way the person fixed it did not apply to me:
Azure Functions .NetCore 3.0 Request.Query throwing "Entry point not found" error
Some Info- may or may not be useful.
When I go through the code step by step in the debugger, HttpRequest.Query shows up properly with all of the keys. I'm wondering if there is some kind of name conflict between HttpRequest object from Microsoft.AspNetCore.Http vs System.Web
If I set my project to use the most recent version of Microsoft.NET.Sdk.Functions, I get a new error instead of an entry point error, I get this instead:
I'm using Visual studio Code.
Can anyone assist? I'd be happy to provide any information needed!

I gave up. I spent about 3 days trying to solve this and this was affecting my ability to work. I just had my entire laptop reformatted and that "fixed" the issue. I tried pretty much everything I could find and nothing worked and I couldn't wait any more. Best of luck to anyone who encounters this!

Visual Studio 2019 intellisense shows red squiggles under every single namespace that is not a .NET one

Visual studio 2019 intellisense shows red squiggles under every single namespace that is not a .NET one. The project builds and runs fine. If I open the solution in VS 2017 it opens fine with no errors.
I have deleted the .vs folder. How can I solve this problem?
edit:
It seems the shared projects have been lost. If I right click to add a reference the other projects cannot be found. I tried removing a project from the solution and re-adding it but the "shared projects" list is still empty. I suspect this is related to problem where intellisense can't find them either.
If I open the solution up in VS2017 after this, everything works fine so it appears to be related to VS2019 only.

Our solution is documented here:
https://github.com/dotnet/roslyn/issues/40082
I was able to track down the root cause for this issue, and also
provided a workaround to #rolandh offline.
Tagging #jasonmalinowski, who is expert on VS project system layer on
our team, and #tmat who has been investigating how to properly report
VS-specific diagnostics in Roslyn. Let me expand on the findings:
Provided solution has a two projects which have a circular reference
Project P1 has a ProjectReference to project P2 and project P2 has a metadata Reference to P2.dll. Latter gets converted to a project
reference via our metadata to project reference conversion logic.
Above configuration leads our VS project code to throw an
InvalidOperationException in CheckNotContainsTransitiveReference
over here when attempting to add project and metadata references.
Above exception seems to get handled somewhere down the call stack,
so there is no user visible impact. However, it causes the project
state for P1 to get corrupt - it ends up with no documents, no
references, etc. This leads to a ton of cascading intellisense
errors in all projects referencing P1.
Building the project/solution on command line succeeds as P1's
reference to P2.dll is unnecessary.
Unfortunately, the above InvalidOperationException does not
translate to any diagnostic in the error list, so user is given no
information about what went wrong under the covers and how to
resolve their issue. Ideally, the circular reference, or in fact any
such project system anomalies for which we throw exceptions in the
Workspace layer, should be translated to diagnostics in error list
by VS layer, so it helps the user towards fixing their
project/solution. #jasonmalinowski do we have any issue tracking
such work? I can file one otherwise.
Basically somehow we got a circular reference in our projects (not possible via the UI) which causes a bug in the intellisense engine.
Removing this circular reference resolved the issue.

Solution fails to build w/ missing auto-generated .g.cs file for the first time, succeeds on second build

I'm building a WPF app w/ Visual Studio 2015 (Update 3), and—at least by now, I'm not sure for how long this has been the case—every time I make a change and compile, I'll get a failed build w/ the error
6>CSC : error CS2001: Source file 'C:[...]\Obj\Debug\AnyCPU\GeneratedInternalTypeHelper.g.cs' could not be found.`
If I just build a second time, though, it works just fine.
This smells to me like a dependency on another file that is generated afterwards or something like that, but I haven't been able to find out what it is, a google search didn't net anything either, and neither did a search through my project what this file is used for in the first place (the name suggests its purpose, but I don't know where exactly it is used).
It might also be that the (group-policy-mandated) Anti-Virus is holding an exclusive lock on the file or its dependency for a moment too long, and VS stumbles over that, I think I remember a problem like this at my last job, but I'm not sure that is the case (and I can't simply disable the scanner for a check, it's completely locked down and I don't want to violate company policy for trying to circumvent it).
Any ideas? It's not critical since it's easy to work around, but it's annoying and I don't really want to check in the project like this in the end.

I had the same issue and i found why it happened (in my case).
Every project of our solution has the same output folder.
The file GeneratedInternalTypeHelper.g.cs was generated at the same place for each project.
The build order/dependencies were computed and Visual Studio found that some project could be build in parallel.
In Tools > Options > Project & Solutions > Build and Run you can find the option "Maximum number of parallel project builds.
After changed from 8(in my case) to 1, no more files generated at the same time :)
It is a little slower to compile but really less annoying than compile multiple times... \o/

An alternative solution is to add project dependencies in the solution for the projects you don't want to build in parallel.
With this you can keep the parallel project build for the other projects.

I have just chased down the same error. In my case it was caused by Git checkout inserting a "%20" into the folder name of the solution where a space was expected. Replacing "%20" with space fixed all these missing *.g.cs errors. Thought worth mentioning here.

Getting mysterious build error after upgrading solution to Windows 8.1

I have used windows store apps 8.0 in my project and upgraded it to be 8.1. And also upgraded Visual Studio from 2012 to 2013.
First, I got an error that cannot use the Microsoft.VCLibs Version 11.0 and 12.0. So I removed the 11.0 version.
And then I got this errors:
I tried to find some information on the internet, but nothing.
Also when I double clicked on the error it doesn't bring me to the error's spot.
I have tried to do many things, and nothing helped, so I decided to write this post.
Can someone help me resolve this errors?
EDIT:
I am adding some more information, maybe this can lead to the problem:
Solved:
With the help of Hans Passant the errors have fixed. The problem was that I had this duplicate on my resource file:
I did it twice because one is for buttons (that has content), and one is for message dialogs on code behind.
In Visual Studio 2012 this code was working fine, but somehow, not in Visual Studio 2013.
I deleted the row of Cancel.Content and the errors disappeared and it works fine :)

Here is somebody else with the same problem.
I'll just copy Caplan's guidance. Look through the .resw file(s) in your project and look for a duplicated "Cancel" resource. I should note that intentionally forcing a duplicate resource produced another message when I built the program on VS2013:
1>MakePri : error 0x80073b0f: Processing Resources with error: Duplicate Entry.
1>MakePRI : error 0xdef00532: Conflicting values for resource 'Resources/String1'
Same message from either duplicating the resource in the same .resw file and by making a copy of the .resw file and adding it to the project. So Caplan's explanation isn't exactly a slam-dunk. I'd pay attention to other projects in your solution that might also have a resource named "Cancel". A likely scenario when your solution has a dependency on VCLibs, that sounds like you are mixing C# and C++/CX.

I came across this MSDN URL which seemed to be pretty helpful.
2 snippets in particular you could try:
You could actually have a duplicate resource entry in your project file.
Your obj files could have become corrupt, you need to clear out your obj files (although I haven't seen this problem for a while in my
team - it might be fixed in 2008).
If you are using a custom culture, perhaps with the .Net RegisterCulture method, ensure that the culture has been registered on
your computer. If you've reinstalled your OS and installed VS2008 and
you can't build due to this problem it could be because you need to
register your custom cultures before you build. This error seems to
be thrown when msbuild cannot find the culture.
Alternatively:
PS - There is also a Visual Studio 2012 Update 3 available that could possibly help?
Visual Studio 2012 Update 3
I hope this helps.

A similar error can also occur if you update a Nuget package in one project, but not in another dependent project also using the same Nuget package.
i.e. it can be a version mismatch error when referencing different versions of a dependency across two dependent projects.

I don't know if you have tried re-installing VS 2013, I was getting the same error but it was resolved when I re-installed.

In my case, after retargeting a working Win8 App for Win81 App, was UI string. Imho it is correct but soehow the VS2013 has some problems with it.
Locations SomeString
Locations.Text SomeStringForUI
Removing the one of them solved my problem.

Recently i got a similar build exception on my UWP Project
MakePri : error 0x80073b0f: Processing Resources failed with error: Doppelter Eintrag.
MakePRI : error 0xdef00532: Conflicting values for resource 'System.Design/ClassComments1'
I found a lot of information about the error but no solution. It looks like the error must be in the entry application project but it isn't.
In my case the VS integrated automaticly a reference to System.Activities because a made a mistake.
After i deleted the wrong reference, it works fine again.

Got this error in a UWP Xamarin.Forms project when a fellow developer referenced System.Web in a PCL that the Xamarin.Forms PCL references.
For more info:
Add System.Web Reference To A Windows 10 Universal App

Script# and compiler problems

I've just come across a pretty strange problem with VS2010 and Script#, which most of the time I am able to re-create.
In my simple scenario I have 2 projects in my solution; a standard Asp.Net MVC2 Web Application, and a Script# jQuery Class Library. I created a static class (attributed with [Imported]) with a static method on it, the intention being that I can map this class in code to an external Javascript library, as described in the documentation.
However, it seems that whenever I decorate such a class with [IgnoreNamespace] to achieve this goal, the project stops successfully compiling but doesn't give me any feedback as to why it's failing (no errors in the error window, for example). It's not easy to get rid of either, as Visual Studio seems to get into a permanent state of not build failure; removing the classes and project files doesn't solve it, nor restarting visual studio. The only way I can get VS to build the project successfully is to delete the project entirely, create a new one then add the files back in, which is annoying to say the least.
With a verbose build output setting, I get the following:
Target "AfterCompile" in file "C:\Program Files (x86)\ScriptSharp\v1.0\ScriptSharp.targets" from project "e:\project\local\ScriptSharpDemo\Scripts\Scripts.csproj" (target "Compile" depends on it):
Task "ScriptCompilerTask"
Done executing task "ScriptCompilerTask" -- FAILED.
Done building target "AfterCompile" in project "Scripts.csproj" -- FAILED.
.. which doesn't tell me whole lot.
There have been a couple of times where I have managed to create this type of class and then successfully build, but mostly I can reproduce this problem pretty reliably.
At this point I'm inclined to think that the bug lies with Script#, but would just like to have that confirmed, and to find a possible work around if there is one.

Just in case anyone is having a similar issue, I've found the cause of the problem.
When adding a class using this method, or copying in a file from another project for use within Script#, this causes a reference to System.dll to be added to the project. This (understandably) causes the project to stop compiling without error.
It would be nice to have a warning about this or for Script# to somehow detect when this situation occurs and/or create a new template for when I use 'Add class' or import a file, but it is just a convenience issue and at least now I can painlessly get my project compiling again just by removing this reference.

When trying to make my project build again, I came across the following, possible solutions:
The "Home\HomePage.cs" and "Shared\Utility.cs" must not be deleted and remain where they wre initially created
The "Home\HomePage.cs" and "Shared\Utility.cs" must be the last entries in the "*.csproj"-file. After them, no "Compile" tag should follow
Problematic calls to "Script.Literal" might cause silent fails - especially be careful when having parameters (like Script.Literal("{0}.doFoo()", variable))
The same seems to be true for "String.Format" when the format parameters are invalid
Namespaces and folders seem to cause many problems, putting all classes into the same namespace and all classes into the same folder might help

I tried all of the suggestions that have been given here, but continued to see the issue. Eventually, I determined that the cause in my situation was that I had added an [IntrinsicProperty] attribute to one of my properties. Removing it solved the issue. Don't ask me why this was causing a problem, but I thought I would share this solution in case others run into it.