Many .NET developers sooner or later will have to do interop with unmanaged world. Let’s say for example that you need to use some Dll written in C++. Passing integers or floats relatively easy, but things are much more complicated with strings. Many C++ Dll still uses ANSI strings, so let’s talk about them. Normally when you read Microsoft documentation you will be slightly confused. Some pages states that you have to use UnmanagedType.LPStr like it stated here: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.unmanagedtype?view=netframework-4.8#System_Runtime_InteropServices_UnmanagedType_LPStr. And that looks like correct for ANSI strings. Moreover, you can try it and it works just fine.

Some pages stated that you have to use IntPtr: https://docs.microsoft.com/en-us/previous-versions/ms172514(v=vs.100)?redirectedfrom=MSDN and then manually prepare strings to pass

Many developers for Windows used to fact that all resources that you allocated in your application will be released when your process is closed. And in fact, many developers read Windows API function description by diagonal ignoring most of it. Please read it carefully and I will explain why.

Few years ago, developers started to hit the same problem: application failed to start with some stupid unrelated error and in fact all application failed to start again with some strange error. Restart always fixes this problem, so we blamed Microsoft and move on. In some cases, you even cannot restart your PC due to the same strange errors. But we time it start to happen more and more often. And

If you are developer, you should never use anything related to current directory. If you do, then with almost 100% probability you will regret that you did. Let me explain why you should never use it.

Current directory is state of your process. And it is not read only. Some code in your process can change it. And imagine you tested your code and made sure that it is safe to use current directory in that particular place. But tomorrow you or someone in your team will  refactor this code and move it in different part that it is not safe. For example, move that code to function that executes in different thread or threads. Good luck debugging that.

But