I am currently building a WPF application and have some system wide settings. Where is the best place to store these settings? App.Config file, Database or some other sort of XML file? (need to read and write).
My other issue is the application has two states (i.e. Admin Mode, Client Mode) and depending on the state the application behaves differently i.e. (Shut Down, Restart, Lock, Unlock etc.) This seems like a good case to implement the State design pattern... but the issue I am facing is that the running application is itself the context class. I am a bit confused... should I be implementing the Singleton Pattern? How is this best implemented?
In general it is often easiest to store application settings using the Settings page of the Project Designer in Visual Studio. These settings can either be stored per user or per application. Either way, they can be saved easily by calling:
Properties.Settings.Default.Save();
They can be accessed similarly:
Properties.Settings.Default.FirstUserSetting = "abc";
You can find out full details by taking a look at the Managing Application Settings page on MSDN.
Regarding your second question, I would recommend using the State Design Pattern. Unfortunately, I didn't understand your problem with that, so please let me know what your issue is and I will try to address it.
Related
I'm developing an application to run in background. This application is used to capture user’s activity on their system. Application is working very fine.
Now, I need to display a windows form over locked screen. Just like this:
Can any one help me! How can I show any windows form over locked screen?
Not possible, for security reasons no application should be shown when the screen is locked.
The only thing remotely similiar might be a Kiosk App:
Is the Windows.ApplicationModel.LockScreen namespace available for non-kiosk use?
There are a few different things here that are probably confusing things. unfortunately they are not very common scenarios so documentation is lacking.
You can use the Windows.ApplicationModel.LockScreen namespace for customising the display of the lock screen. This can be used to change the wallpaper or notification counts. It is probably the most common form of lock screen customization as it can be done by any app.
You can also use the functionality in this namespace to create an alternative lock screen. This could have different behaviour to the process of swipe up and enter password/PIN or Microsoft Hello face detection.
Creating such an app and distributing through the store requires extra permissions than 3rd party developers typically have.
"Kiosk mode" apps are created as apps that run above the lock screen. Such apps have no real connection to lock screen replacements but are related in their use of similar underlying elements of the OS.
In terms of what you are trying to achieve, it sounds like you should be able to do this by declaring the windows.lockScreen extension and then using LockApplicationHost to do the actual unlocking. As mentioned above the lack of a way for 3rd parties to distribute such apps through the store means there is a lack of documentation in this area but it should be possible.
One thing to take note of in such an app is an under even greater memory/resource constraints than a typical app and so you should keep this in mind during your planning and development.
I know this is an old question but for anyone still looking:
It is a security risk don't do it.
If you still want to do it this could help: SampleHardwareEventCredentialprovider
You will have to play with WinAPI and CredentialProviders but it is working demo and will show simple windows dialog with a button at lockscreen
A call to all Win32 developers... I'm developing an application in C using plain Win32. I wanted to ask about Windows development standards regarding these things:
Is there a standard Windows error log api? For example if my client uses my app and it crashes, I would like them to send me the error log and I would prefer this being a standard location so they can maybe access it with a standard Windows log utility.
My app needs to store settings information. I think the registry is the standard utility for this task. Is that right?
My app needs to store and retrieve files that it downloaded from the internet - images, executables etc. Is Application Data/myapp the standard location to store this type of information?
My app needs a very straight-forward database - I'm using CSV for this. I basically need to store and retrieve this type of data so I'm just serializing a .csv file from Application Data/myapp. Is there a better Windows standard way of doing this?
That's all for now :). Thanks!
Is there a standard Windows error log api?
There is the Windows Event Log, but I don't think you want a typical user having to go into it to extract your logged information.
You probably don't want to log by default, unless you're shipping questionable pre-release code. When a user is experiencing problems, then you have them turn logging on. In this case, I recommend placing the file somewhere that typical users have experience with, like My Documents.
By the way, if you're writing a standalone application and want the best possible information in the event of a crash, look into minidumps. Here is a Codeproject sample.
My app needs to store settings information
Yep, registry.
My app needs to store and retrieve files
Yes, App Data. Just be sure to use SHGetFolderPath and CSIDL_APPDATA.
My app needs a very straight-forward database
There's nothing wrong with CSV for simple data. You could store the data in XML and use MSXML to process it, if you prefer. I've used SQlite in the past when I needed fast, lightweight storage of more complicated data.
Is there any way i can load a silverlight application from isolated storage and replace the current application ?
Short answer: no, you cannot do this. You could however store a dll, read and load it via reflection if you are in a trusted out-of-the-browser application.
Anyway I don't believe this to be a very good practice, it's very likely there is a different better way to solve your particular problem.
You can't replace the currently running application from within Silverlight code.
However you could create a single application to act as a shell. You could store assemblies or entire Xaps in isolated storage. Using the AssemblyPart class allows you to load an assembly from this storage, create an instance of an entry type and execute an entry point method.
The big caveat would be that this "stored application" would have to be coded specifically to work within your shell. You would need to provide your ways in particular to allow for "application" level state to be accessed and a means of loading content assets such as images.
Does anyone else think Silverlight 4 security is a bit screwball?
Look at the following scenario:
Silverlight when set to trusted app, and run out of browser mode allows you to browse for a file using the file open dialog.
You require the name of the path of the file to open it up from any COM automation. For example (excel/word) but this could be anything.
It is impossible to get the full path of the file from the dialog because of security restrictions
You can however using COM FileSystemObject - do what ever you want to the users file system, including create folders, move and delete files.
So in other words, why all the fuss about security in Silverlight, which actually hinders real business use cases, when its possible to access any file anyways using COM?
To say it another way, if a user runs a malicious silverlight app, its unlikely they'll say - oh well it was COM at fault. The COM was afterall being called by a Silverlight app.
Here is what I mean....
User browses for file - c:\myFile.xls
Silverlight prevents you from getting the path (for security reasons)
Silverlight only lets you work with my documents
Using COM you can do what ever you want to the file system in the background anyways. Including copying that file now to my documents, if only you knew the name! But besides that you can wipe any file potentially if its not in use.
In my opinion Silverlight security model is flawed, either they should have given developers full trust and allow us to run apps as if they were running locally
or
Not allowed Silverlight to access COM.
Is it just me, or can anyone else see that its a bad implementation?
This triggers security alerts:
OpenFileDialog flDialog = new OpenFileDialog();
FileInfo fs = flDialog.File;
string fileName = fs.FullName;
This doesn't
dynamic fileSystem = AutomationFactory.CreateObject("Scripting.FileSystemObject");
fileSystem.CopyFile(anyFileName,anyDestination);
I don't agree with your point of view. The fact that you can do pretty much anything that an installed COM object will allow you to do is not a reason to modify a whole bunch of existing Silverlight code to allow you to do those same things.
Why? Because in the process of opening up that code there is also an increase chance that in some unintended way that same code could get run when the Silverlight component is not running in trusted mode. If that were to happen even once the media would all over it in a shot and Silverlight's reputation would, probably unfairly, be in tatters.
Personally I'm quite happy with the very cautious approach to security that MS are taking with Silverlight.
some Silverlight controls such as the OpenFileDialog work in both trusted and untrusted mode. These controls have been ported from previous versions of Silverlight where the new levels are elevated trust were not a consideration.
Thank you to Anthony for pointing this out.
Developers need to be aware of the definition of trust we are discussing here. Running a Silverlight application in full trust with elevated privileges IS NOT the same thing as running a local Silverlight Windows based Application. It is also far more restrictive than ActiveX.
Its possible that the trust here provided in Silverlight suits your particular business requirement. It is however likely that there are scenarios where you will find Silverlight too restrictive, its best to do your research upfront, and run code samples to ensure you can do the critical stuff, before jumping in head over heels.
Microsoft guarantees that public Silverlight API has the same behavior for both for Windows and MacOS platforms. So the functionality is many ways limited by the common denominator and technical feasibility. Please treat COM introp as a specific case addressing only Windows platform and only in full trust mode and it is not going to work the same for other platforms. So the security restrictions are valid as they are the same for both worlds in terms of API reuse.
I agree with the original poster. I think it's bad implementation. We are given a built in dialog to browse for a file, including directory structure. We can select a file and get a FileInfo object, but security prevents us from getting the FullName (directory and file name). Why? How does that improve security? What's the point of the open file dialog to begin with?
And as the original poster mentioned, with those dynamic objects, we can modify the local file system... which seems like the possible security hole.
All I want to do is read some data from an excel file... a way for my users to import excel data into the application, and the file could be saved anywhere on their machine. These are sales reps using an excel files to record orders locally until they can get to an internet connection. Who knows where they all save that file... so I'm not going to try to suggest we tell them all to store it in the same place in "my documents". I'll get laughed at if I suggest that.
It seems like it should be incredibly simple. But that "security measure" that keeps us from getting the directory the user chose from the built in open file dialog makes it so that we can't use the dialog for the purpose it was created for.
So what's the alternative? Is there a way to pick files using those dynamic objects? Do I have to write my own file selection tool using those objects that can modify the file system? Since I don't need anything but to read the file, and because I read something somewhere that we do have access to the file stream... is there a way to using the file stream to open up the file for reading using the AutomationFactory?
I've tried to use IsolatedStorageSettings in my ViewModel, but these are not getting retained across browser refreshes (F5).
for example;
//look in the IsoStore for remembered details
IsRememberMe = IsolatedStorageSettings.ApplicationSettings.Contains(Constants.LOGIN_REMEMBERED_USERNAME);
if (IsRememberMe)
{
UserName = IsolatedStorageSettings.ApplicationSettings[Constants.LOGIN_REMEMBERED_USERNAME] as string;
}
Do I need to do something differently in my MVVM ViewModel's??
EDIT
It's worth noting that this code is sitting in a referenced project - so ultimately a seperate XAP file to the parent XAP that is loaded in the browser - might this cause the settings to be lost on each refresh?
THanks,
Mark
Well...
In my case I have issues using Application Isolated Storage, each time I deployed a new version of my app (just for instance changing the color of a button I lost my Iso Storage :-().
I move to use SiteStorage instead of Application level, and it worked:
http://www.tipsdotnet.com/TechBlog.aspx?PageIndex=0&BLID=13
On the other hand what I had done with Iso Storage is perform CRUD on folders and files, not sure abou that other kind of settings.
HTH
Braulio
I would think one of two things is happening here. Either your binding isn't working correctly in both directions so either the persistence or the retrieval code is never hit. Or, you're storing these values in application level iso storage from two different applications (or something to that effect). Make sure your code is being hit in both cases (storing and retrieving) and make sure you're accessing the iso store from the same place (if you're using application level isolation, store/retrieve from the same application, etc).