"Merk" <A@B.COM> wrote in message
news:Oc7XYgQGHHA.420@TK2MSFTNGP02.phx.gbl...
> I'm looking for a safe and maintainable way to store connection string
> info (connecting to SQL Server 2005 from .NET 2.0 Windows Forms client
> app); things like server name or IP address and database name. I need to
> provide the client application with this info for connecting to both a
> test SQL Server and a production server.
>
> I would prefer to NOT hard-code this info into the client application, and
> App.Config seems rather unsafe as the users can change it with a text
> editor.
>
> What are my options?
>
> Thanks.
>

"RobinS" <RobinS@NoSpam.yah.none> wrote in message
news:oaidnVxoK_LF6uvYnZ2dnUVZ_uSdnZ2d@comcast.com...
> We store it in the Settings under the Project Properties. We're using
> Windows security, so there are no usernames or passwords involved.
>
> You could store two connectionstrings there (type = ConnectionString,
> Scope = Application), then refer to them in your code as
> My.Settings.ConnectionStringTest or something like that. (That's
> what it's called in VB -- C# has different syntax.)
>
> Robin S.
> -------------------------------------
> "Merk" <A@B.COM> wrote in message
> news:Oc7XYgQGHHA.420@TK2MSFTNGP02.phx.gbl...
>> I'm looking for a safe and maintainable way to store connection string
>> info (connecting to SQL Server 2005 from .NET 2.0 Windows Forms client
>> app); things like server name or IP address and database name. I need to
>> provide the client application with this info for connecting to both a
>> test SQL Server and a production server.
>>
>> I would prefer to NOT hard-code this info into the client application,
>> and App.Config seems rather unsafe as the users can change it with a text
>> editor.
>>
>> What are my options?
>>
>> Thanks.
>>
>
>

Merk wrote:
> I'm looking for a safe and maintainable way to store connection string info
> (connecting to SQL Server 2005 from .NET 2.0 Windows Forms client app);
> things like server name or IP address and database name. I need to provide
> the client application with this info for connecting to both a test SQL
> Server and a production server.
>
> I would prefer to NOT hard-code this info into the client application, and
> App.Config seems rather unsafe as the users can change it with a text
> editor.
>
> What are my options?

"Bruce Wood" <brucewood@canada.com> wrote in message
news:1165428968.519048.26950@n67g2000cwd.googlegroups.com...
>
> Merk wrote:
>> I'm looking for a safe and maintainable way to store connection string
>> info
>> (connecting to SQL Server 2005 from .NET 2.0 Windows Forms client app);
>> things like server name or IP address and database name. I need to
>> provide
>> the client application with this info for connecting to both a test SQL
>> Server and a production server.
>>
>> I would prefer to NOT hard-code this info into the client application,
>> and
>> App.Config seems rather unsafe as the users can change it with a text
>> editor.
>>
>> What are my options?
>
> I've been looking into this same question in my spare time. One option
> recommended by Microsoft is to store the connection string in
> app.config, but to store it encrypted. Here is a good place to start
> reading:
>
> http://msdn2.microsoft.com/en-us/library/89211k9b.aspx
>
> The difficulty is that all of the detailed articles I've found on
> securing connection strings by encryption refer to Web applications,
> not WinForms applications. There's probably a good reason for this:
> encryption and decryption can work on a per-machine basis: one way you
> can encrypt a string is to do so on a particular machine in such a way
> that only that particular machine can decrypt it. That works great when
> the only machine running your code is your IIS server. It doesn't work
> at all well if you distribute your application to all and sundry.
>
> I've yet to come across samples for a WinForms solution. Perhaps
> there's a way to encrypt a string and store it in the configuration
> file, then hard-code the secret portion of the key into one's
> application. Hardly textbook security, but better than plaintext.
>

Merk wrote:
> I appreciate your post. Perhaps a lazy-yet-effective way to go would be to
> Base64 encode the string. That would "raise the bar enough" to satisfy my
> desire to simply not have clear text in App.Config while getting around the
> additional difficulties of encrypting the text. Thoughts? (and yes - I know
> Base64 encoding is not the same as encryption - not even close).