If this happens, use the checklist
- For some versions of Verify.xUnit, you need to add [UsesVerify] attribute to your test class.
- Verifier.Verify methods are asynchronous, make sure the calls are awaited.
Bruce Ng's software development blog
An archive of solutions of programming problems I have faced in my career
If this happens, use the checklist
Reference SO question and answer:
Try to fix this by installing “Internet Information Services” => “World Wide Web Services” => “Application Development Features” from “Turn Windows features on or off”
Maybe you need to install ASP.NET 4.8, or something similar, try out few things depending on your project.
If you face this errors when running some ASP.NET applications, it is because of assembly redirection.
At the moment I’m not sure how it works, but if there are some assembly redirection written in your web.config file, comment them out and it may solve the problem.
This turned out to be a problem when NuGet packages are checked in to the source control system in folder packages.
The problem occurs when
When VS tries to restore NuGet packages, it will try to access the existing packages already in TFS, because the packages are read only as the workspace is a server workspace. VS will be denied access to the path to the package.
To solve this, either delete the existing packages, or turn off automatic package restore in Visual Studio.
The correct way is to have no packages checked in to the source control system, either keep the project up to date with NuGet, or create a local cache of packages.
WebAPI will add these if there is attribute [Serializable] added to the model.
Removing the attribute will solve this problem.
This is because when the query is sent to MySQL, it’s encoded using the default charset, which is usually set to latin.
For some reason, it’s not a problem in Windows.
For PHP, when creating a connection to MySQL, call set_charset to set the character set to UTF8.
For ASP.NET Core application, set the charset in the connection string: CharSet=utf8.
This happens if ASP.NET 1.1 is installed and then uninstalled for some reason.
To fix, open IIS Manager, go to the website, under ISAPI filters, remove the aspnet_filter handler. After that, the error should go away.
Search for “Turn Windows features on or off” and enable features under IIS -> WWW Services -> Application Development Features.
Enable ASP.NET 3.5 or 4.8, one of the features will enable handlers.
Maybe <handlers> is for ASP.NET Http Handlers.
If you encounter this error, check the parameters of the action method, there may be no model binders configured for one or some of them.
The content-type header of the response is affected by the accept header of the request. This is not very obvious at first.
So when you register a custom media type to the JsonFormatter or XmlFormatter, the content-type header will not be changed depending on the type of the response object. Rather it matches the accept header in the request.
If the accept header in the request is not accepted, then the services will default to application/json or application/xml.
Example: let’s say you have a service model called Student, a custom media type “application/mycompany.com+json”, and a web service endpoint that returns a student by ID.
If you just use the browser to make a request to this endpoint, the content-type header in the response will likely be set to “application/json” or “application/xml” depending on your preferred setting and browser.
However if you set the accept header in the request to “application/mycompany.com+json”, the content-type type response header will be set to the same type.
There is no mapping between the types and the service model from the backend side.