The solution you are proposing to store the string in a DLL encrypted solves no security problems. It is wasted effort. You could store the connection string in your app and accomplish the same thing. But none of this really matters because you can easily extract encrypted strings from binaries just as easily as you can from the config file (which is where they normally reside). So you're just adding work that makes you think it is safer when it actually doesn't do anything.
If you must store sensitive data in your config file then encrypt the connection string as @Sreeju Nair mentioned. But bear in mind that anybody with a debugger can still get the unencrypted string.
If your app is deployed on a server and you are concerned about the server being compromised then store the sensitive data somewhere else such as in Key Vault or another third party "password" management system. Then have your app call that. But be aware that if you put calls directly into your app then anybody with access to it can do the same thing.
If you just want to keep sensitive data out of your source control then consider storing the data in Key Vault (or similar) or in environment variables on the server (or somewhere on the server more secure).
If your app is a client app then there is no place to store this data securely. In most cases it is better to have it call an API that then talks to the secure backend to get the data needed (e.g. a database). For per-user data you could store it in their per-user directory structure so others wouldn't have access (except admins) but it depends on what you're storing.