A quick workaround is to set NLA off under “Allow remote access to this computer”. Just uncheck the option that mentions NLA.
This is not recommended for production environment, just for development and testing.
Bruce Ng's software development blog
An archive of solutions of programming problems I have faced in my career
A quick workaround is to set NLA off under “Allow remote access to this computer”. Just uncheck the option that mentions NLA.
This is not recommended for production environment, just for development and testing.
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.
In the address bar, enter chrome://inspect
They changed how to do this.
When this happens, there can be a few reasons
-You attached to the wrong process.
-The build profile was changed to Release instead of Debug, thus no symbols are generated for debugging.
-You opened multiple instances of Visual Studio or programs that lock the PDB file, so when you make a new build the PDB file fails to be regenerated to match the new DLL.
-There are assemblies with classes with same name in the same namespace (for example DI may be configured to load different assemblies depending on some configuration). Visual Studio load the debug file for the wrong assembly when you are debugging some code. VS may assume that there is only one implementation of a a class in same namespace.
Steps to resolve
Make sure you attach to the correct process.
Make sure the build profile is Debug.
Clean and rebuild the solution.
If there are multiple assemblies with classes with the same name, try deleting the one that is not in use and then rebuild. Best option is to avoid classes with same name in same namespace. VS will be confused.
Last step, log out and log in again, or restart the computer to kill the processes that are locking the PDB. It could even be some Visual Studio bug.
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.
It seems that when child component has its own state which is created by passing from the parent component’s state, if the parent component changes the state and try to re-create the child component with this new state passing in as a parameter for the constructor, the child somehow still uses its old state.
Maybe the rule of thumb is, state should only be changed by the direct owner of the state, not the containers?
Anyway I solved this issue by converting the child component into a StatelessWidget in Flutter, still trying to get my head around this Unidirection data flow pattern created by React.
If this happens, make sure clipboard sharing is enabled in the guest settings.
If it still doesn’t work, re-insert the VBox Additions ISO to the guest OS and reinstall VBox Additions, reboot guest OS and try again.
It may work for a while until eventually breaking again if Virtualbox is updated. After upgrading Virtualbox, usually there will be a new version of VBox Additions.
When the response header is too large, nginx will reject it and return 502 Bad Gateway, this is because the default proxy buffer size is not large enough.
If you inspect the error.log file under /var/nginx, you will find this error
upstream sent too big header while reading response header from upstream
Change the following settings under location to fix this issue by making the buffers larger
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
After fixing this, if you encounter error: Request header or cookie too long. You can fix it by setting the buffer size for client header under server configuration context.
large_client_header_buffers 4 24k