Bruce Ng's software development blog
An archive of solutions of programming problems I have faced in my career
I faced this issue, turned out when using docker cp to copy files to the container, the files were owned by root user and other users didn’t have read permission. This is because the files were copied from shared folder in Windows host to the linux VM.
Because only root can read, I couldn’t restore the DB using the copied file as the server cannot read the file.
Doing a chmod to add read permission before copying into the container solves the issue.
This was a stupid one.
Use SSMS to check if the MSSQL instance is configure to allow logging in using only Windows Authentication.
Switch to both SQL Server Authentication and Windows Authentication and restart the service.
While working with ASP.NET Core, I find that the [ApiController] attribute does a lot of magic to my controller.
https://docs.microsoft.com/en-us/aspnet/core/web-api/?view=aspnetcore-3.1#apicontroller-attribute
It will automatically throws 400 bad request error back to the client, parse the service model from the request payload, and a bunch of other things.
I’m still not sure how model binding works without this attribute, maybe I would have to decorate the service with binding attributes for it to work.
When developing ASP.NET Core applications, if for some reason the breakpoints never hit when the browser tries to refresh or makes requests to the server.
One possible reason is that the responses are cached by the client, this is especially the case with static files. Use Ctrl-F5 in the browser to clear the cache. If the browser uses the data in the cache instead, there won’t be any requests to the server.
This of course applies to any other backend technologies, no requests, no breakpoint hits.
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.
If you want to change a .NET Core project Docker target, for example from Windows to Linux, edit the project file and and change the value of property <DockerDefaultTargetOS>.
Change from Windows to Linux and vice versa.
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.
When got this error using NHibernate, it’s likely that your mappings and data models are not registered with the NHibernate configuration object.
Simply add the Assembly that contains the mapping files and the model declaration and it will work.
Also, make sure the mapping files are configured to be embedded resource in the project.
Use listConfig: { listeners: { } }
In Visual Studio, under Connected Services, right click on the service you want to update and choose “Update….”.