Using XAML C# in Windows "Metro" Apps how do I go about playing a certain video file. Examples:
D:\video1.wmv
\\MEDIAPC\video2.wmv
The only way I managed to get this working so far is by using FilePicker, but I don't want to use this as I already have a list of files to play.
I have tried to use GetFileFromPathAsync but I keep getting permission / access issues
await StorageFile.GetFileFromPathAsync(#"D:\video1.wmv");
Apologies if this has been answered I just couldn't find an answer that fits my problem.
If your D:\ drive is a non-network resource try adding the Removable storage application capability. This can be accomplished by double-clicking on the Package.appxmanifest and navigating to the Capabilities tab. By default your application (assuming it is a Windows Store app) only has access to local files packaged with your app or files stored in local/roaming/temp folders (usually reserved for Application state).
If your data is stored on a Network resource that requires authentication you will want to enable the Enterprise Authentication capability.
You may also want to fiddle with the Home and Work Networks for the \MEDIAPC\ files if you aren't accessing resources that require network authentication.
Further Reads:
Accessing data and files
How to load data from files
App Capabilities Overview
Related
I want to supply a bunch of files with my Windows Phone 8.1 app which are necessary for running the application. I searched on the net and found that this page. But I don't know which place in particular is the ApplicationData.Current folder. What I want is the following:-
Can I create a folder called Resources or use the existing Assets folder in my Project tree and save the files in there.
If yes, then how can I access that folder from within my App i.e. how can I open and close files in that Directory(relative or absolute addressing format to be used)? If you can provide a one or two line code for this, it would be great.
Do I have to use the ReadTextAsync method to read the entire text of the file into a string or are there any other methods.(The System.IO.File.ReadAllText() method is not accessible when creating Windows 8.1 Phone app).
Thanks in advance.
Your App is installed on SD or Phone, depending on user Settings on the Phone. You can't normally access those files eg. by browsing files while Phone is connected to computer - the apps are Isolated.
Depending on your App:
if it's 8.1 Silverlight then you will find all the information here at MSDN.
if it's 8.1 RunTime then take a look here.
Although you can't access files inside your App from outside the App, from WP8.1 you have access (read/write) to SD Card and other KnownFolders.
EDIT - you can also access your files by using Uri schemes.
Can any one tell me how I can create a folder in local drives through c# code in winrt. I am creating a windows 8 app. I have to create a folder in local drives like in d drive or e drive through my winrt app to save some data in it. I don't want to create folder in local storage.
Can anyone tell me how i can achieve this.
WinRT restricts the filesystem locations that are available to applications.
See this detailed post for additional information: Accessing data and files
Short answer: WinRT restricts the locations that your app can access, and it may not be possible to do what you want.
However, if you are saving data related to your application, what are the reasons for not using local app data?
There is only one way to access file system locations that the app does not have access to. The FileOpenPicker or FolderPicker. Once a user has selected the file and folder for the backup, you can maintain this access for future use by using the Windows.Storage.AccessCache namespace and the appropriate methods. Here is a link to the related answer: Save File or Folder For Later Use .
Best of Luck
My problem is I have a LOB application that can possibly save multiple files (number of files only known at runtime) based on user inputs. Saving this as a single file and having the user break them apart, or zipping them up as a single file is not an option unfortunately.
SaveFileDialog seems suited to only save 1 file at a time. Third party controls may be an option but I have yet to find any that serve this purpose. Thanks!
The browser security model guidelines (outside of Silverlight) prohibit web application logic (script or otherwise) from having direct access to the local file system.
Consider what havoc a malicious web site could wreak on your computer if web application script could write arbitrary files to arbitrary locations on the local hard disk!
For this reason, Silverlight isolates your code away from the local file system. Silverlight manages the Open File or Save File dialogs, but your web app code never gets to see the full path of the file names directly for security reasons. The Silverlight dialog only supports working with one filename / path at a time.
Silverlight does offer isolated storage on the local machine in which your web app could write multiple files. However, as noted in comments, isolated storage is isolated in both directions - it keeps the web app isolated from the local file system, and that makes it difficult for the end user to access the contents of the isolated storage outside of the browser. (Difficult enough to make it infeasible for nontechnical users, but not difficult enough to call isolated storage "secure" from malicious snooping).
Short of writing your own native executable browser extension (for each different browser brand and version you wish to support) (or non-sandboxed javascript plugin for some browsers), I don't think there is a way for a web app to push data into multiple local files convenient to use outside of the browser in one user action.
Since this is an LOB in the intranet zone have you considered asking your users to install the app as OOB with Elevated trust. This would allow you to write files to the users Documents folder without the SaveFileDialog.
The other option is to zip the files with a single SaveFileDialog call.
There are no other Silverlight oriented solution.
Is it possible to write a filesystem for Windows in pure usermode, or more specifically purely in managed code? I am thinking of something very similar to GMAILFS. Excluding what it is doing under the covers (GMAIL, Amazon, etc..) the main goal would be to provide a drive letter and support all of the basic file operations, and possibly even adding my own structures for storing metadata, etc..
Windows provides several approaches to building a user-mode file system for different purposes, depending on your storage location and features that you need to support. Two of them, Projected File System API and Cloud Files API were recently provided as part of the Windows 10 updates.
Windows Projected File System API
Projected File System API is designed to represent some hierarchical data, such as for example Windows Registry, in the form of a file system.
Unlike Cloud Files (see below) it does not provide any information about file status and hides the fact that this is not the “real” file system. Example.
Windows Cloud Sync Engine API
Cloud Sync Engine API (Cloud Files API, Cloud Filter API) is used in OneDrive on Windows 10 under the hood. It provides folder content loading during the first request, on-demand files content loading in several different modes, and offline files support. It integrates directly into Windows File Manager and Windows Notification Center and provides file status (offline, in-sync, conflict, pinned) and file content transfer progress.
The Cloud Files API runs under regular user permissions and does not require admin privileges for file system mounting or any API calls. Example.
Windows Shell Namespace Extensions API
While Shell Namespace Extension is not a real file system, in many cases you will use it to extend the functionality of the Projected File System and Cloud Files API. For example, you will it to add custom commands to context menus in Windows File Manager as well as you can create nodes that look and behave like a real file system (again, applications would not be able to read or write to such nodes, this is just a user interface).
Cloud Files API is using a namespace extension to show your sync root at the top level in Windows File Manager.
It's difficult. I'd take a look at some projects which have done some of the hard work for you, e.g. Dokan.
Yes. It's possible and has been successfully done for the ext2 filesystem.
Note that you will need to write your own driver which will require Microsoft signing to be run on some OSes.
Sure, you can abstract the regular file operations and have them running in the cloud (see Google Apps, Amazon S3, Microsoft Azure etc.). But if you'd like to talk to local devices - including the local HD - you'll have to use system APIs and those use drivers (system/kernel mode).
As long as all you want is a storage service -no problem. If you want a real OS, you'll need to talk to real hardware and that means drivers.
Just as a reference - our Callback File System is a maintained and supported solution for creation of filesystems in user-mode.
Is there any way to create a virtual drive in "(My) Computer" and manipulate it, somewhat like JungleDisk does it?
It probably does something like:
override OnRead(object sender, Event e) {
ShowFilesFromAmazon();
}
Are there any API:s for this? Maybe to write to an XML-file or a database, instead of a real drive.
The Dokan Library seems to be the answer that mostly corresponds with my question, even though System.IO.IsolatedStorage seems to be the most standardized and most Microsoft-environment adapted.
Depending on what type of virtual drive you wish to build, here are some new OS API recently introduced in Windows, macOS and iOS.
Some of the below API is available as managed .NET code on Windows but many are a native Windows / macOS / iOS API. Even though, I was able to consume many of the below API in .NET and Xamarin applications and build entire Virtual Drive in C# for Windows, macOS and iOS.
For Remote Cloud Storage
On Windows. Windows 10 provides Cloud Sync Engine API for creating virtual drives that publish data from a remote location. It is also known under the “Cloud Filter API” name or “Windows Cloud Provider”. Here are its major features:
On-demand folders listing. Folder listing is made only when the first requested by the client application to the file system is made. File content is not downloaded, but all file properties including file size are available on the client via regular files API.
On-demand file content loading. File content can be downloaded in several modes (progressive, streaming mode, allow background download, etc) and made available to OS when application makes first file content reading request.
Offline files support. Files can be edited in the offline mode, pinned/unpinned and synched to/from the server.
Windows shell integration. Windows File Manager shows file status (modified, in-sync, conflict) and file download progress.
Metadata and properties support. Custom columns can be displayed in Windows File Manager as well as some binary metadata can be associated with each file and folder.
On macOS and iOS. MacOS Big Sur and iOS 11+ provides similar API called File Provider API. Its features are similar to what Windows API provides:
On-demand folders listing.
On-demand files content loading.
Offline files support.
File Manager Integration. In macOS Finder and iOS Files application you can can show file status (in the cloud, local).
I am not sure currently if files/folders and can show custom columns in macOS Finder and store any metadata.
For High-Speed Local Storage
On Windows. Windows provides ProjFS API. Its main difference from the Cloud Sync Engine API and macOS/iOS File Provider API is that it hides the fact that it is a remote storage. It does not provide any indication of the file status, download progress, ets. The documentation says it is intended for “projecting” hierarchical data in the form of file system.
You can use the Dokan library to create a virtual drive. There is a .Net wrapper for interfacing with C#.
Yes, use the classes in System.IO.IsolatedStorage
The contents of My Computer can include Shell Namespace Extensions. These COM objects run inside the main Explorer process, as do many other shell extensions. Using C# for such extensions is a bad idea, since your extension cannot control which CLR version Explorer.exe can use. And Microsoft allows only one CLR per process.