Tuesday, February 2, 2010

Weven compatibility

I finally bought Weven, to test our new installer. One of our new features is that you can select a logo and text message to put on the header of our PDFs that are emailed and printed. The way I do this, is that I create a handouts folder in the app data section where our config data is stored, and I create each PDF when it's requested, if it's not already there. When the user changes the settings, I delete them all. This works fine in Vista.

On Weven, it was throwing an exception ( the code then just delivers the unmodified PDF ). I posted about this in an online forum and was surprised to find a number of people are reporting trouble accessing the app data area in Vista and Weven. In fact, one person told me they store all app data under My Documents now, because it's the only place they can trust to get access to.

I did some more digging and my PDF library was causing the exception, when I try to load a PDF in a subfolder of my application. I replaced that by inserting a call to File.ReadAllBytes, so that it used that overload. I assume the library (it's Syncfusion, FWIW, and I found the library in general to be excellent, well documented and easy to use), is asking for full write access when given a path, and does not provide an overload to ask for read access only.

So, I solved my issue, but now I'm worried.

1 - Other developers have abandoned the appdata areas altogether because of problems with access ( which I assume means that the shadow directory, which is it's own nightmare ( imagine support calls that the app won't remember preferences, for example ) is not reliable, either). So, am I playing with fire by assuming that just because MY setup of Vista and Weven work now, that it will work on all machines ? Yes, I've logged in as a guest and tested that, etc. but still.....

2 - The Syncfusion code works in Vista but not in Weven ( I always use a default OS install and assume that's what most users have ). That means that Weven is even more strict in what it allows. I can see why my code should not be able to just write to files in the program files area, but surely anything in my app folder or a sub folder should be excepted from that rule ? I guess it's not, and that's why we need to use the app data area, but why was it working in Vista then ?

Is it possible that the people reporting issues have just made some sort of mistake ? Perhaps, but these are people I've known for a long time, and who I trust, and I doubt they moved all their app data to my documents without some serious testing to prove they had an issue. As I can write to files in that area, I can only assume that some combinations of settings in Vista and Weven make that impossible. Given what a fiasco Vista was from the start, I can't help but start with Weven feeling a little cautious and concerned. I lost my MS MVP for being critical of Vista, yet I hear sales people in computer stores all the time selling Weven by telling people that Vista was a nightmare, and Weven has fixed the problems, so it seems problems with Vista were widespread. I do think Microsoft just flat out mishanded that ( and I only complained in public because, despite being an 'MVP', I was given no other channels in which to talk about my concerns, and when I did find channels for other issues ( like VS bugs ), I was always ignored anyhow.

Has anyone else had any new security issues from moving to Weven ? Anyone had issues with access to the app data area ?


  1. This came up in a discussion between Luc and myself yesterday on CP: http://www.codeproject.com/Forums/1649/Csharp.aspx?fid=1649&df=10000&mpp=25&sort=Position&tid=3384938

    The reason is that files/folders in AppData are write/modify for the creator only. Other users only have read/execute permission.

    I have posted a rough Tip/Trick that addresses it here: http://www.codeproject.com/tips/61987/Allow-write-modify-access-to-CommonApplicationData.aspx

  2. I don't know why these posts don't get emailed to me anymore, but thanks for the tip, I'll look that up.