I am currently attempting to read in files (that the user selects) and store them (with their permission). The trouble I am having is that, having SkyDrive installed and enabled, I have what are known as SMART files, noted with a LocallyIncomplete attribute.
What this means is that the SkyDrive app stores a reference to this file in SkyDrive, but does not actually pull the whole file until the user requests it (by using it in some way). This works totally fine if they access the file in the picker via the SkyDrive app (the drop down at the top left). It even marks those that are not completely offline as LocallyIncomplete while not marking those that are available offline.
The issue (that I was lucky enough to find) is that I have included a folder in my SkyDrive app inside of a library (specifically, my Documents library). This makes all of the files show up in the picker, as it should.
If I try and open any SkyDrive files from the library, then not only does it mark all of them as LocallyIncomplete (even when the SkyDrive app does not), but it throws a native IOException, which is impossible for my app to catch. This happens even if the file being requested is locally available through the SkyDrive App. This is consistently reproducible on my machine.
Upon further investigation, it seems that I can check the Provider property to make sure that files with the LocallyIncomplete attribute come from the SkyDrive app, which is good at least (in that I can avoid an uncatchable exception). This will work for now as a Workaround, but it's less than ideal.
Also, I haven't been able to find any mention of this on Connect/MSDN. I'm hoping a MSFT-y wouldn't mind double checking to see if there's a bug filed for this before I file one myself, as I haven't been able to find one.
Thanks.
LocallyIncomplete means the file is not 100% downloaded to the user's machine.
You can check this way
if (!file.Attributes.HasFlag(FileAttributes.LocallyIncomplete))
{
//dostuff
}
where file is of type StorageFile
Related
I want to transfer a file to an Android device using a USB cable and file explorer, and then access it in my Xamarin.Forms app.
As far as I understand there are two ways to do this (and please correct me if I'm wrong):
Since it's an image file - Just put it anywhere and let some
background task find it and add it to what seems to be a virtual
folder of Images. And then access it there.
A more general solution - browse to that specific folder.
Both solutions rely on using FileInfos etc. but unfortunately the folder structure is much different than I see using windows explorer - instead of Alarms, Android, etc. which I see on windows explorer - is see cache, config, etc. using C#, and access to some like data is not allowed (I get an exception). I also tried finding information on how I would search for all images on the device, but either it's not as simple as I thought it would be, or I'm using the wrong keywords.
The file will be put there by a user, so it cannot be added to the project's resources.
Xamarin has a nice way to navigate the files in android, using Android.OS.Environment.ExternalStorageDirectory.Pathwhich you can concatenate with your directory/filename so you can save/access data.
If you want to open the android dialog box so the user can find a file in its device, you can take a look at: https://developer.xamarin.com/recipes/android/data/files/selecting_a_gallery_image/
Remembering that you need to add the READ_EXTERNAL_STORAGE permission to your android manifest file and check runtime permissions. Runtime permissions can be easily checked with https://github.com/jamesmontemagno/PermissionsPlugin
OK, so my hard disk just crashed. Big deal. All my web dev code that was on it went along with it, and now I'm running ddrescue on Ubuntu trying to recover whatever data I can recover. The hard disk keeps disconnecting and sometimes it can quit responding for a long time so it's really a pain in the ass.
Anyway, back to the main topic--I have my web dev code which was packaged and uploaded to Azure; now what I'm wondering is if it's possible to obtain all my .cs files from the VM. I noticed approot and siteroot folders, but all I saw were the views, the .asax file, some other misc, stuff, nothing with the .cs extension.
Is there any way I can get a copy of the code I packaged? or (as a last resort) any way to get the .cspkg file and work from there?
The site you are seeing on the web role and inside the cspkg file is the output of the compile, so you can't get the original .cs files out of them. That said, you can use a tool like Reflector, Just Decompile, or a variety of other decompilers out there to reverse engineer your compiled bits into something that will be very close to the original C# code (not I'm assuming this is your own code, or code that doesn't have a provision against reverse engineering). This at least will let you use the bits on the webrole to get the majority of your code back, then review it to see how good a job it did.
Note, you can open the cspkg file. It's just a zip file. You can rename with a .zip file extension and open it up, but you won't find the .cs files in there. The only time you find this to be the case is if you have multiple websites within a single web role. The default packager for Windows Azure doesn't compile the additional sites, only packages up all the files in their root directory. Not at all helpful for actual deployments really, but this won't likely help you.
You are likely well ahead of me on this, but I'd recommend using a personal source control system of some sort to avoid this issue in the future.
I am trying to access information under C:\Users\Public\Documents\ which displays as C:\Users\Public\Public Documents\ on explorer. Is there a way to be able to access the DirectoryInfo of a directory under the junction using the pathname displayed in explorer in .NET C#?
When/how are you expecting to get a C:\users\public\public documents path?
If a user goes to copy/paste from Explorer, the C:\users\public\documents path will be copied into the clipboard. Going through a SaveFileDialog also produces the valid path.
If you need a way to access Windows 7 libraries, you can give the Windows API Code Pack a go. You can then access "Public Documents as KnownFolders.PublicDocuments, for example. From what I can see (I've never used it before), there's still no way to reliably turn C:\users\public\public documents into a DirectoryInfo, but you might have better luck digging through the docs.
So I have been writing to
Environment.SpecialFolder.ApplicationData
this data file, that upon uninstall needs to be deleted. I am using Innos Setup to build my installer. It works great for me. So my data file hangs out in the above path and I do that cause when I used to try to write it to
Application.ExecutablePath
certain boxes I tested it on would throw a nasty error at me trying to write data there. I do research and somehow its not always writable and its how i came up with the Environment.SpecialFolder.ApplicationData
That is why my data file now resides in the SpecialFolder.ApplicationData. Trouble is if the user uninstalls and reinstalls I need that file gone. It might be a short coming of my knowledge of Innos but I cannot figure out how to know where that file will be to tell innos that.
So then I thought I had a clever solution: Innos can run a file when its done uninstalling, so I had my program create this file "uninstallData.bat" that says:
del "the file in my special folder application data path"
and I wrote it out to drumroll
Application.ExecutablePath
(yes it was a while in development and I had forgot it was't doable.)
So of course I am back to square one, I need to write a file to a path Innos knows about {app} and I need it to be able to delete my data file in the SpecialFolder... i don't care how I do it i just need that file gone.
Are there other Environment. or Application. approches I have missed? Maybe somewhere that is viewable by an uninstaller AND can be written to?
As an aside, I am not sure why my box I develop on can write to the application folder no issue, but it cannot on other boxes... weird.
Any input would be great sorta lost as to how to crack this nut.
The environment location is in the user profile. If there are multiple users on the machine, and they all run the application then a copy of the file will be in each profile.
The path also depends on the OS.
Regardless, the current user's app data location is pointed to by %APPDATA% and %LOCALAPPDATA%. These Windows environment variables should be available within Innos.
Appliccation.ExecutablePath is not writable per standard defintions - the program files folder should never be manipulated by running applications. Ther area number of special folders for that. Nice that you finally found.... what is properly documented by Microsoft for a LONG time now (minimum 10 years).
I suggest you get a proper installer - WIX comes to my mind. Your problem is totally unrelated to C# - it seems to be totally a "crappy installer" issue. Or provide a PROGRAM (not bat file) to run at uninstall. What exatly is your problem there?
I currently store a serialized XML file in the application directory that contains all changes specific to the program operation (not typical system or user configuration). Weeks ago, we started running into problems where it would not save correctly (read my previous question about this).
Long story short, we finally discovered that Windows 7 (and sometimes Vista) has an issue with writing into the application directory (specifically anything under Program Files). Now, if this were a normal configuration file I would simply store it under the user's APPDATA folder, but it is not normal. We run this on our own instrumentation, and misconfigurations are 99% of the reason customers have issues running our software. So we need this file to be accessible such that they can easily find it and email it to us. Appdata is hard enough for experienced users to find, much less very non-technological people.
We've also tried running it as Administrator, and making folder permissions wide open (we have control over every computer it runs on; it will never run on some random person's machine). But, these sometimes work, and sometimes do not.
The worst part is that when I write the file back out, it doesn't even throw an error; it simply writes it to some temporary directory that expires at some unknown point in time. Weeks later, our user will have an issue, and the configuration file is all messed up.
So, my question is where should I be storing this file, if not in Program Files? Should I just put it in APPDATA anyway, and make a small utility that emails it to us automatically in case of a problem? Or can I leave it in Program Files, but change some specific permission or registry key to allow it to operate normally?
It depends on whether or not the user needs to edit the file directly. If not, you should put them in %APPDATA%, which you can access via:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Otherwise, you might put it in My Documents:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
Either way, putting it in Program Files is not a good idea. As you discovered, there are permission issues, even if running as Administrator.
For those users, you could build a button in that would open this directory. You could put it in an inconspicuous place that you could later direct them to.
For users that have an email client on their box, you could have a button that would create a new email with subject and automatically attach the file to the email.