1) I use Visual Studio 2008 (C#)
2) I want my desktop application to "remember" certain settings (preferences) for every user individually.
3) The application would use its own database of users (logins + passwords), so they have nothing to do with Windows accounts.
How can I accomplish that? Trying to find an answer
4) I've found the "Using Alternate Sets of Settings" subject on MSDN => http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx - but
5) it suggests that even these alternative settings need to be added in design time. That's a bit of a problem, because:
6) I don't know in advance, how many users would be in the database - and I want the "main user" (admin) to have an option of adding more accounts any time he wants.
So
7) how do I accomplish that?
So far I thought about:
8) using isolated storage files? (but they, too, are user-scoped in the sense of referring to Windows accounts)
9) deriving my own class from ApplicationSettingsBase class and supplying it with a SaveAs() method (which it lacks by default)?
Thanks for any answers / suggestions.
If my problem is not quite clear, I'm happy to clarify
If you have a database that stores users and passwords, why not store the application settings there as well? I'm assuming you're using SQL Server (Express or commercial)
All "Settings" are in .NET are key, value pairs, and I don't see why you couldn't accomplish this exact same functionality with a name value pair in the database.
I've found that the "Settings" and Configuration management tools are confusing and tricky to use, so if you have a database with users in it already, you might as well leverage your existing infrastructure.
You could use a SQLite database to hold all the data. (See System.Data.SQLite)
You should think about using the ASP.NET Membership provider. It allows for per-user personalization settings as well as 'all user' settings.
It was built for web sites, but you can configure it for use in a desktop application pretty easily. Also, there is a whole API that is already written for it.
Related
I am learning C# using Visual Studio and I am running into some issues.
I am developing a Windows form application. The application is meant to track user's running stats.
In settings: they select how many days they run and for each day they add their workout (ie: 1: 100m sprints 2: 50m sprints 3: Run a mile).
Then in the main windows form the user will be able to add their times and save it. Meanwhile a graph is projected of their times- this will allow the user to track their progress.
My question is where should I store their times? Right now I store all settings in the settings.settings doc. For the times should I use the settings file or a SQL database of some sort?
SqlCE or SQLite or any other simple inproc database will be better than Settings file.
Settings are not meant to grow with every user input, this is a task for a database, also it will be much easier to query your data using SQL.
Answering your question in comments:
There is a difference between user data and user preferences. You have to decide which is what in your app.
I would go with Settings file with everything regarding user preferences. Like form layout, colors, sounds, window size and so on.
Since Settings managing framework is pretty sophisticated, you will save yourself some time designing tables for user preferences and developing access to that tables.
Another possibly bright side of Settings file - it can be edited manually with text editor.
It is not possible to answer you without a lot more information about what a "user's running stats" is and how it is used. I can give a few general guidelines, though.
System.Configuration.ApplicationSettings are designed for customizing an application for a specific user; for example, what language the user wants the application to use, where he wants windows to appear, or default values. Settings are part of the application; they are created when the application is installed and deleted when the application is uninstalled. If multiple users run the application, each typically gets their own settings. You typically define settings when you create the application and users never add or remove them.
Databases are used to persist user data. They are typically not tied to a specific user or application; users add the data, which is available to other users or applications. Applications typically aren't installed with all user data, nor is user data deleted when the application is uninstalled.
SQL databases are used for relational data; data that has internal structure, like "all users must have exactly one address", or "any user may have zero or more phone numbers". If your data is not relational you do not need a relational database.
These are general guidelines, specific applications may do things differently for specific purposes. If you tell us more about your application we will be able to provide more specific information.
I'am programming a Windows 8 Store App (Metro Design) with C# and XAML using Visual Studio 2012.
There is no need for a database server with multi user support etc.
I want to store my data in a local database and don't know which database is suitable for my needs.
Maybe SQLite? Or are there solutions that fits better for Windows Store Apps and integrates better in Visual Studio?
The app is kind of a calender and the database should store the user data that consists of the dates, tasks and so on.
SQLite is supported for WinRT.
http://visualstudiogallery.msdn.microsoft.com/23f6c55a-4909-4b1f-80b1-25792b11639e
SQLite is the recommended database to be used for Win 8 Apps.
Links for implementing the same
http://timheuer.com/blog/archive/2012/08/07/updated-how-to-using-sqlite-from-windows-store-apps.aspx
http://code.msdn.microsoft.com/windowsapps/Using-SQLite-Asynchronously-b8372137
https://visualstudiogallery.msdn.microsoft.com/23f6c55a-4909-4b1f-80b1-25792b11639e
Ok, this is a great question that I had to learn the hard way. By default WinRT applications do NOT have access to, directly at least, to any type of database structure. This means no Express, Compact, CE, SQLite etc.
There are three ways around this. Do not use a database and instead use a local file structure where you store and retrieve your data. XML works very nicely with this because you can maintain many of the same features a database would give you.
The second option is to use IndexedDB. It is similar to a cookie style local storage model where files are saved in your apps local apps folder.
The third and final option is to use web services. WinRT does have access to the internet which means you can write API and WebServices that can be called. This does mean that you need to have a server running which is connected to a master database. When your app needs data it calls your web service and obtains what it needs.
Overall, for the application you are describing the first option may best suite your needs. Keep a local XML file in your apps folder and read/write from it.
My question was marked as a duplicate of this question (although it was about C++ not C#). I thought I should still post my findings here. C++ apps have another alternative:
Extensible Storage Engine (ESE)
The list of all such API available for Store apps can be found on this link under the section Jet.
As one of variant:
Devart LinqConnect for Metro – a fully-functional high-performance ORM solution for developing Windows Store applications using either of LINQ or ADO.NET to access data.
http://code.msdn.microsoft.com/windowsapps/A-Simple-Windows-Store-85f29843#content
or next link can be usefull to
http://social.technet.microsoft.com/wiki/contents/articles/18417.windows-store-app-with-a-sqlite-database.aspx
I am working on a windows app. The user has to register first to use this application. So in order to store user information, I am using MS-Access as a database. There is not much information to be stored as this application will be on individuals machine. There are few settings and some user information to be stored.
What I am feeling is that with the use of MS-Access, my application will be dependent on other application as MS-Access. It is not necessary to have the MS-office on the end user's machine.
So can you suggest me the best way to store the data safely without any dependence.
One thing I want to clear is that, the information will be of different types like it will consists of user information, some folder/files paths and some other information. I would like to keep these information separate from each other.
Thanks
Abhie
I think I found the solution.
Best practice to save application settings in a Windows Forms Application
I hope this will help others facing same problem.
Stackoverflow Team You are doing fabulous job. One suggestion; can you put some chat option for developers to discuss their problems. I think this would make it more easy to find answers to complex problems...:)
Regards
you need to include Access Database Engine drivers in the client PC, in order to connect it .
MS Access Database Engine
If you're using .NET, the best bet for getting the recommended folder locations for application data (e.g. your mdb file) is probably best retrieved using Environment.GetFolderPath
See:
http://msdn.microsoft.com/en-us/library/system.environment.getfolderpath.aspx
You're likely interested in ApplicationData or LocalApplicationData for user specific data or CommonApplicationData for data shared by all users as your storage location (and then the proper company / product subdirectories appended to it).
What is the best way to deal with User specific settings with an Application Level Excel 2010 Add In?
In my scenario, a user loads Excel with an Add In installed, this adds a new Ribbon option which allows a Winform to load. The Winform collects a single piece of data and then must attempt to persist that for the current user.
Does Excel provide a mechanism for this? Is the approach similar to vanilla Winforms (i.e. maybe IsolatedStorage)?
Many thanks,
Andy
Use the registry - that's what Excel does for writing various bits of information while it is running. The user's hive of the registry (HKEY_CURRENT_USER) is always accessible, so there are no permissions issues, and it is fast and unintrusive.
.NET has easy access to the registry through the Registry class : http://msdn.microsoft.com/en-us/library/microsoft.win32.registry.aspx.
Migrating (rewriting) a whole portal originally made in .net to shareopoint doesn't seem like a very easy thing to do.
I've been assigned such task and now i'm just learning, planning and starting to get things practical in order to accomplish it faster.
It's not exactly a question, it should be a discussion about it and may help others who might get to do the same job further on.
1 - There's something like a "message board" in the current portal, which i'm planning on building with a blog site kind, what do you sugest?
2 - as asked in another question, i have to manage users, and the local active directory is organized and reliable, so i guess that's what i'm going to use
3 - There's got to be a way to store files, images, documents and having version controlling in some of them.
4 - There's got to be a customization in design and a cleaning in the default controls of sharepoint masterpage (which may be useless for the desired purposes)
5 - About 30 local users and being accessible from the internet (local server) in case our consultors have to access it from clients
6 - i have available a version of the Visual Studio 2010 (already with the graphical webpart designer) because the company i work is MS gold partner.
7 - I'm going to program webparts in c#, and the designing part is still a mistery to me, since i'm not that familiar to shareopint yet.
I'd like some tips, links and answers.. i'm going to be watching this question from now on and answering any other information.
1.) SharePoint 2007 has some blog/wiki/board functionality but it's very immature. I tried to get my team to use them but the user interface is lacking and it is challenging to enhance those elements. SP2010 might offer a better experience though.
2.) User management in SharePoint is easy to perform but difficult to manage. Establish processes for adding/modifying end users and keep the number of people with that ability to a minimum. Otherwise it gets out of control and you end up not knowing who has access to what. I would also suggest relying on AD groups as opposed to giving individuals specific access in sites.
3.) Document storage is SharePoint's forte, I think you'll be impressed.
4.) SharePoint branding will require some time but other people have it down to an art form. Note that some pages (referred to as Application pages) shouldn't be fully controlled. Also note that you don't want to remove controls from the master page as some functionality in SharePoint assumes the controls are there - rather it is better to hide them using CSS.
5.) This sounds like a bad idea. SharePoint exposed to the Internet is supposed to be severely locked down - but if you lock it down (i.e. remove access to Application pages), the functionality that you seek won't be available. Have you considered an intranet and separate extranet?
6.) Should be okay, VS2010 is supposed to be a better development experience with regards to SharePoint.
7.) Keep your branding and functionality separate and be sure to deploy them using solution files (as opposed to working directly with the file system). Also, never ever read/write the database directly.
I think you'll find that replacing a custom intranet with SharePoint is a common task but there will be a learning curve. The hard part will be branding and data migration. End users will reject the new system if it is slow - so be sure to get the architecture and configuration right before launch (might require a consultant).
1 - There's something like a "message
board" in the current portal, which
i'm planning on building with a blog
site kind, what do you sugest?
SharePoint discussions are perfect for what they are intended ... small targeted discussions. A forum is very different. It is a centralized area with multiple threads with different topics. You can try CodePlex (which is your friend)
SharePoint Forums
2 - as asked in another question, i
have to manage users, and the local
active directory is organized and
reliable, so i guess that's what i'm
going to use
AD is perfect if you already have it ... nice thing is that you can use the Profile page to update AD information which syncs ... you have a lot of capability with this. But, one of the main benefits is that SharePoint can support multiple authentications. You can extend a SharePoint site and plug in a different authentication (like SQL Auth) and then multiple sets of users can interact on the same sites with different permissions. Not to mention that SharePoint doesn't just provide site access but you can make security granular all the wat down to individual items in a list or library.
3 - There's got to be a way to store
files, images, documents and having
version controlling in some of them.
This is where SharePoint has the most capability OOB.
4 - There's got to be a customization
in design and a cleaning in the
default controls of sharepoint
masterpage (which may be useless for
the desired purposes)
We have a completely customized MasterPage complete with code behind. You need to know about Feature Stapling and Feature Receivers. Also use Heather Solomon's website
5 - About 30 local users and being
accessible from the internet (local
server) in case our consultors have to
access it from clients
SharePoint seems almost overkill for this number of users.
6 - i have available a version of the
Visual Studio 2010 (already with the
graphical webpart designer) because
the company i work is MS gold partner.
Get the Visual Studio Extensions for SharePoint
7 - I'm going to program webparts in
c#, and the designing part is still a
mistery to me, since i'm not that
familiar to shareopint yet.
Look into Application Pages instead of WebParts ... Application pages are way more flexible for custom forms than web parts. Web parts are only usefull for when functionality needs to be available on an ad hoc basis so that you can allow users to drag the functionality onto a page or if you need to restrict functionality to specific sets of users (since layout pages are available to all sites).
The answers to this person's similar but not identical question may be helpful: Sharepoint for a C# Asp.net Developer
There's a lot of help available in other existing SO questions. Just click on the "sharepoint" tag, then sort by votes, and you'll find a lot of interesting reading.
Regarding 7 - Programming web parts:
Have a look at SmartPart on CodePlex. This is a fairly easy way to create simple web parts especially if you have some ASP experience.