Develop Reference

How can i protect my .net application from decompilers?

Okay so i have this C# application that connects to a database has the login and all that stuff but what if some guy just downloaded a decompiler saw my code got the connection string from my DB and did whatever he felt like?
How can i protect myself from that? And even if i could protect my connection string how could i protect my acctual code?

You should never store critical information in your assemblies, exactly for this reason. There are numerous ways to obfuscate the information but they only delay the inevitable.
Remember: Security by obscurity is not safe
Access the data on a server-side application and pass it to an authenticated client instead.
Restrict the Database User Account to the minimal required rights (if you only need to read information - make sure it doesn't have write access, etc.)

but what if some guy just downloaded a decompiler saw my code got the connection string from my DB and did whatever he felt like? How can i protect myself from that?
That's a shame, isn't it ? There are only a few things you can do for that :
Use a VPS ($$) and store the login part of your code online. You can, for that secificly, use LiteCode, and here is a tutorial : https://github.com/debug-hf/LiteCode-Example/
Use an obfuscator to avoid decompilers and hackers to look at your code. The best so far is http://netguard.io . It includes free plans and all the premium plans are fully secured. All your strings are scrambled, melted, stored secretly in the file. Famous deobfuscator, such a De4Dot cannot handle it even if it handles more or less every obfuscators on the market !
Hope it helps :) Cheers

Connection strings can be encrypted in the config file
Connection Strings and Configuration Files
However, you cannot truly protect your code from people wishing to view what it does, you can only make it harder by obfuscation.
I would add that a proper security model could restrict access to both the physical files, and the database 'data', but that does depend on your deployment model.

You should store your connection string in your app.config or web.config file.

How do I modify config file at runtime

I need to change the config file myApp.exe.configat runtime. How to make sure that the program would be started to work with a modified file without leaving the program?
It may be necessary to use a ConfigurationManager.
Thank you!

It's definitely possible, I did this at work a while back. Essentially, you can load a new app.config file into memory, then tell .NET to use the new file. From that point on, all variables in the Configurarion section change when read using the standard .NET calls.
Sorry I cant give specifics, you might have to Google some more - but at least you know its possible!!
Having said this, I believe this is the wrong architectural path to go down. Far better to store your settings in an external file in your own format. It really is a royal pain to update app.config, and if we hadnt had to do it for compatibility reasons with legacy assemblies it would not have been worth it in the least. The legacy assemblies used WCF which in itself was a mistake. WCF is a ghastly architectural morass, with few redeeming features compared to any of the modern alternatives.
Update
See Overriding App.Config settings.
See Change default app.config at runtime.

Safe and secure way to keep encrypted data and private key in C# Dll

The question about storing connection string in safest way.
My current approach (Don't laugh)
1. Wrote RSAEncryption program and passed connection string to generate cypher.
2. Stored Cypher and private key in Resource file
3. Runtime retrieved encryption file again.
My concern of using config file
- I am creating library so projects who will use my dll will need to copy my config file which I dont want
Please tell me best practice to store connection string inside the dll.
Regards,
Omkar

There is a built in mechanism in .NET to encrypt sections of config. The beauty is you can use DPAPI and have the machine itself create the key, so nobody knows what it is except Windows. The best thing is you get this pretty much for free (small learning curve) and the learning curve is easily handled with a quick Google search on encrypting configuration files. May not fit all scenarios, but it is more likely to be secure than a quickly envisioned alternative.
The only issue here is if this is shrinkwrap ware (ie, you are selling software), but there are ways to handle that by having the install require network and adding the bits they can't know while you encrypt only go into memory during install. :-)

Where to store application settings

I am creating an app that reads some info from a scale via RS232 serial port connection. There are a couple of types of scales that are in use, so I would like to store specific settings for the scale in my program. What is the best way to do this? Via app.config? Or should I put the values in a database?

It really depends on where will these configurations be used?
If you are working on a distributed huge system, which means these configurations are probably shared/used by other systems. You'd better store it in the database, with a common protocol which other related systems agree with.
On the other hand, if these configurations are used for a small application, storing them in a config file(or an xml file whatever you like) is suggested because, you don't need a gun in order to kill a mosquito.

app.config would be the easiest option for you. I think a database might be a bit overdoing it for just some settings, but if you wish to use something outside of what is offered by VS (namely app.config) then you could always whip up a quick custom XML settings file. All depends on what you wanna do with it and how comfortable you are with the other technology.

Is the information chaging ? that means when you ran ur app , would it be the case that information is updated ?
if the information is static and do not change frequetly , you can store in the app.config.
or in a xml file and you can read that information lately.
but if the information is dynamic then you need to create a model and expose scale information through model's peroperty.

Do not forget the registry.
Use the registry when:
You need your settings to be accessible for a domain admin
you need to secure some settings (using Windows security)
(You can make some settings read-only)
There are a lot of small settings that change very often

If it's simple and straightforward than app.config is the way to go - you don't need to set up a database and you get to use simple built-in interfaces.
If you choose to go with a database check out mysql for a simple file based database that has a simple deployment scheme.

Understanding .Net Configuration Options

I'm really confused by the various configuration options for .Net configuration of dll's, ASP.net websites etc in .Net v2 - especially when considering the impact of a config file at the UI / end-user end of the chain.
So, for example, some of the applications I work with use settings which we access with:
string blah = AppLib.Properties.Settings.Default.TemplatePath;
Now, this option seems cool because the members are stongly typed, and I won't be able to type in a property name that doesn't exist in the Visual Studio 2005 IDE. We end up with lines like this in the App.Config of a command-line executable project:
<connectionStrings>
<add name="AppConnectionString" connectionString="XXXX" />
<add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>
(If we don't have the second setting, someone releasing a debug dll to the live box could have built with the debug connection string embedded in it - eek)
We also have settings accessed like this:
string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];
Now, these seem cool because we can access the setting from the dll code, or the exe / aspx code, and all we need in the Web or App.config is:
<appSettings>
<add key="TemplatePath_PDF" value="xxx"/>
</appSettings>
However, the value of course may not be set in the config files, or the string name may be mistyped, and so we have a different set of problems.
So... if my understanding is correct, the former methods give strong typing but bad sharing of values between the dll and other projects. The latter provides better sharing, but weaker typing.
I feel like I must be missing something. For the moment, I'm not even concerned with the application being able to write-back values to the configuration files, encryption or anything like that. Also, I had decided that the best way to store any non-connection strings was in the DB... and then the very next thing that I have to do is store phone numbers to text people in case of DB connection issues, so they must be stored outside the DB!

If you use the settings tab in VS 2005+, you can add strongly typed settings and get intellisense, such as in your first example.
string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;
This is physically stored in App.Config.
You could still use the config file's appSettings element, or even roll your own ConfigurationElementCollection, ConfigurationElement, and ConfigurationSection subclasses.
As to where to store your settings, database or config file, in the case of non-connection strings: It depends on your application architecture. If you've got an application server that is shared by all the clients, use the aforementioned method, in App.Config on the app server. Otherwise, you may have to use a database. Placing it in the App.Config on each client will cause versioning/deployment headaches.

Nij, our difference in thinking comes from our different perspectives. I'm thinking about developing enterprise apps that predominantly use WinForms clients. In this instance the business logic is contained on an application server. Each client would need to know the phone number to dial, but placing it in the App.config of each client poses a problem if that phone number changes. In that case it seems obvious to store application configuration information (or application wide settings) in a database and have each client read the settings from there.
The other, .NET way, (I make the distinction because we have, in the pre .NET days, stored application settings in DB tables) is to store application settings in the app.config file and access via way of the generated Settings class.
I digress. Your situation sounds different. If all different apps are on the same server, you could place the settings in a web.config at a higher level. However if they are not, you could also have a seperate "configuration service" that all three applications talk to get their shared settings. At least in this solution you're not replicating the code in three places, raising the potential of maintenance problems when adding settings. Sounds a bit over engineered though.
My personal preference is to use strong typed settings. I actually generate my own strongly typed settings class based on what it's my settings table in the database. That way I can have the best of both worlds. Intellisense to my settings and settings stored in the db (note: that's in the case where there's no app server).
I'm interested in learning other peoples strategies for this too :)

I think your confusion comes from the fact that it looks like your first example is a home-brewed library, not part of .NET.
The configurationmanager example is an example of built-in functionality.

I support Rob Grays answer, but wanted to add to it slightly. This may be overly obvious, but if you are using multiple clients, the app.config should store all settings that are installation specific and the database should store pretty much everything else.
Single client (or server) apps are somewhat different. Here it is more personal choice really. A noticable exception would be if the setting is the ID of a record in the database, in which case I would always store the setting in the database with a foreign key to ensure the reference doesn't get deleted.

Yes - I think I / we are in the headache situation Rob descibes - we have something like 5 or 6 different web-sites and applications across three independent servers that need to access the same DB. As things stand, each one has its own Web or App.config with the settings described setting and / or overriding settings in our main DB-access dll library.
Rob - when you say application server, I'm not sure what you mean? The nearest thing I can think is that we could at least share some settings between sites on the same machine by putting them in a web.config higher in the directory hierarchy... but this too is not something I've been able to investigate... having thought it more important to understand which of the strong or weak-typed routes is 'better'.