All code that is running is running AS THE USER THAT LAUNCHED IT.
If the developers cannot access the content of the config file, neither can Visual Studio nor the application the developers launch in the debugger.
You seem to have only a single environment, production, where you need at least three. You need a developer environment that the developers have enough access to so they can develop the application and the database. You need a test environment that mirrors production so you can test the application and database changes before you put it in production and also test the deployment of the application and database changes. Finally, and obviously, you need a production environment.
In your case, all three of these need to have their own separate database servers with their own connection strings. They don't need to be the same.
But, it comes down to the point where you absolutely need to trust at least two people with the passwords to the production database. They don't have to be developers but they do have to know what they're doing with connection strings. You cannot avoid this.
But, on top of all of this, you and your SQL DBAs, system admins and networking people need to understand security, in SQL, in Windows Server, NTFS, ... to correctly setup every environment and all of the servers and shares to make sure nobody has more permissions than they need to do their jobs.
I am trying to parse a CSV file having two delimiters, first one is a comma(,) second one is a double quote("). So string related looks like "First", "Last", "123 main st",. Decimals and time is like 120.00, 01/01/2016 1:44:23 PM,.
The issue is when there is a comma in the string field. Like -- "First", "Last", "123 main st","Apple, Inc.","San Francisco".
Initially I tried to load the CSV file using SSIS Package, there is a comments field, which users are to enter comments, as a result the file has data with double quotes in the comments. The package load failed as a result.
The double quotes are no delimiters in the same sense as the column delimiter - they're used to quote strings in order to allow occurrences of the actual delimiter within a string as part of the string. If a CSV-reading code can't deal with that then it's because it's not paying attention to whether a delimiter is within a quoted string or not.
There are several solutions for reading CSV, here's a great one (which will have no trouble with this): A Fast CSV Reader[^]
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
The problem is you're making a trade off. You're giving up the convenience of having a pre-made solution that works for one where you're going to spend a lot of time writing code and testing it, and fixing bugs, and testing it, and testing it some more.
I know of two ways to load CSV with SSIS. The first way is with an OleDB connection (and the ACE engine), but it doesn't work very well. The second way is with a Flat File Connection, which works much better and allows you to specify quotes.
Using columns separator that can apear in column data is a bad idea because it complicate reading and it is possible to do otherwise. It become very tricky when a column can contain both column separator and string delimiter, in this case you almost need to write a program dedicated to reading this particular file. When I generate a CSV file, I use a Tab (chr 9) as a column separator and no " around strings. Since the Tab is only used as column separator, reading is really easy because of the unique usage of the tab.
“Everything should be made as simple as possible, but no simpler.” Albert Einstein