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.
Related
I have two resources of the same kind and want to find a easy way to compare their configuration to find differences.
In my project I have several resources of the same kind but with slightly different configuration. I want to make a list of the configuration differences and want to find a easy way to do so.
I'm quite new to azure but I know there is a Resource explorer who shows me configuration in JSON format, but I'm not sure if this shows me the whole configuration or just a part of it and I don't know how to access it / download this configuration via CLI for comparison.
The resources are of different kind e.g. comsos db, key vault, data lake etc.
Whats the best way to do this task?
As I know, the Azure Storage Explorer will inculde the whole(or close to whole, this depends on specific case) configuration.
If you want to use CLI, you could use this command - az resource show, it shows the details of the resources, just specify the --resource-type with what resource you want.
az resource show [--api-version]
[--ids]
[--include-response-body {false, true}]
[--name]
[--namespace]
[--parent]
[--resource-group]
[--resource-type]
[--subscription]
As mentioned in another answer the azure CLI can help you - but it does not always show the whole picture!
One in a while you will find some configuration that is not expressed in the show subcommand (I know I saw this a couple of times but I can't recall concrete examples, so take this with a grain of salt).
Another thing to be aware of (but that wou can work around) is when you have subordinate ARM objects, like for CDN where you have the CDN profile and then it's endpoints, which are separate ARM objects. Or more complex, cases like Databricks where you have a very simple object that spawn it's own infrastructure in a separate resource group.
But in general, using AzCLI with the show subcommand can help quite a bit.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What is the best way to store user settings for a .NET application?
I have found alot of VERY different examples as to how one would save application settings (per user) from a Winforms application.
I imagine that the correct way to do this is very simple in c# and am hoping someone can enlighten me?
At some point, the answer boils down to a matter of taste. I'd say you'll end up with at least these options:
store it in the registry, where you have the HKEY_CURRENT_USER key. Everything under it is user-specific. This is usually preferred when you want to store a bunch of small key-value pairs. The main advantage of this system is that your settings are easy to find and share throughout several different applications. To follow this path, you can start from here.
using .NET Application settings, provides the easiest way to access your settings at runtime. Again, it's better for using with key-value pairs of small-sized data. IMO, the main advantages of this method is its simplicity and the fact that it empowers you to use some .NET classes as values (not forcing you to convert everything into more basic types). To follow this path, you can start from here.
store it in User Data folders, which are usually hidden under the user's profile directory. This is preferred when you want to store a large amount of data or any number of files. The main advantage of this method is that you can manipulate your data as you would with any files (that may also be a disadvantage). To follow this path, you can start from here.
You can use the settings infrastructure provided by .NET. In your project's property pages, go to the Settings page, and define your settings. You can define the scope of each setting as "Application" or "User". A class will be automatically generated to access these settings from code.
To access settings Foo and Bar, use :
// Read settings
textBoxFoo.Text = Properties.Settings.Default.Foo;
// Write settings
Properties.Settings.Default.Bar = checkBoxBar.IsChecked;
// Save settings
Properties.Settings.Default.Save();
I would use Application Settings. It's pretty straightforward and will take care of some issues for you (such as not having write access to the folder where your app may be installed without administrative access, which rules out directly using app.config for your settings).
I am looking for ways to store data in a Windows Forms application in .NET.
I want to make the input data of a system persistent, so when I close my program and open it again, the data is retrieved.
Which ways of doing this exist besides creating a linked database?
Examples are gladly appreciated.
There are dozens of different ways to store data. It completely depends on what data. Is it:
Just a couple of configuration values? Use the built-in Settings library.
Machine-wide configuration? Use the registry.
Transactional? Use a relational database.
Related but not transactional? Use a lightweight database like SQLite or SQLCE.
Structured but not related? Use XML or JSON files.
Somewhat structured and high in volume? Use a NoSQL solution like MongoDB.
And so on... there are different solutions for every storage requirement and many projects make use of more than one at a time.
An easy way would be to make use of XML.
Using XML in C# in the simplest way
Read/Write Xml document with FileStream
If your data is not mission critical (e.g. user preferences), you could just serialise your objects to file, and de-serialise them next time the app is loaded.
Examples? Do your homework yourself :)
Anyhow, possible ways are:
Registry.
Files. Like Microsoft Word does. Or like an ini file, like most games do for example for their settings
Databaase
Which makes sense depends on what the application DOES and other scenarios around it. A fast answer is not really possible without knowing more.
I have a Windows Service written in C# (.Net 3.5) and I need to store some state somewhere so that next time the service starts up, it knows where it left off.
What is the recommended store for this type of thing? The registry? What if I just put some user settings in a Settings.settings file? Where would the user profile be for a service executing as LocalSystem or NetworkService?
Personally, I prefer the registry for server state storage, provided it isn't a large amount of information.
If you're storing a large amount of information, a local database is another option. Services have the advantage of running under elevated privelidges, so you can typically use local file storage, as well.
If it's a small, fairly simple chunk of data, you can create an XML serializable class and very easily write it to disk on shutdown and read it back on startup. For a simple enough class, you can just add the [Serializable] attribute, and the XmlSerializer will automatically know how to serialize/deserialize it.
If you have enough data that a SQL database would be a better fit, look into SQL Server Compact Edition or the System.Data.SQLite binding for SQLite.
Both will let you create a database as a single file, without having to install any extra Windows services or configure anything. System.Data.SQLite doesn't even need to be installed - it's contained entirely with the .dll that your project references.
In either case, the best location for the file is probably SpecialFolder.CommonApplicationData - I think this ends up being C:\ProgramData\ on Vista, but avoids having to hardcode the exact path.
I would go with a .settings file, since its properties are type safe. This is of course assuming that the service is not going to store a large amount of information. Does it really matter where the system chooses to store the settings file?
I hate to say this, but the best answer is that it depends. Without knowing the purpose of your service, a correct answer can't be given. Having said that... the world is your oyster, so to speak.
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'.