IIS Error: This configuration section cannot be used at this path …

Reference SO question and answer:

https://stackoverflow.com/questions/9794985/config-error-this-configuration-section-cannot-be-used-at-this-path

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.

NuGet package restore failed Access to path is denied

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

  • Automatically restore missing NuGet packages is turned on in Visual Studio.
  • There are NuGet packages checked in to the source control system.
  • The TFS work space is a server work space.

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.

Non-English characters become question marks when inserting into MySQL server in Ubuntu Linux server

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.

Use custom content-type header in WebAPI or MVC.

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.

FaultException with WCF

One of the reasons why a connection to WCF services cannot be made due to security issue is due to time difference between the client and the server machine.

If you found this issue, synchronizing the time between the client and the server may resolve it.