Archived Posts from this Category
Archived Posts from this Category
One of my longest standing pet hates with desktop software developed in .NET relates to the almost inevitable security exception that will occur if you attempt to run it from a network share. Its always one of the first things I notice about software, as I often download and unzip software onto my desktop (which on my work machine is located on a network share) and then attempt to run it in place. Many large and quite impressive pieces of software that get distributed as .ZIP files rather than installers suffer this plight, and a lot of them don’t handle the exception well (One that springs to mind was the much heralded release of NDepend 2.0).
The good news is that this anguish may well be about to come to an end, as Brad Abrams requests feedback about the .NET teams possible plan to make network shares trusted. As he mentions, there really is no good reason not to trust a network share for running managed .NET code - there is no such protection for unmanaged code, and there is little or no way a normal user would be aware of which is .a NET EXE and which is unmanaged EXE.
To answer Brad’s Questions:
A) Have you ever run into this limitation (a security exception when running a .NET application from a network file share)?
I frequently experience these issues - I tend to use this problem (and if its been worked round in the application) as a yard stick as to how well written the application is.
B) How often do you use network file shares for deploying applications (managed or otherwise)?
Most of my development is web based, however for utilities written for in house use we tend to distribute them on a network share - being able to run these in place would be a great help, as updating them would be easier.
C) If you think we should make this change, when would be a good time? Is it something we should do sooner in a service pack of the .NET Framework or later in a full release of the framework. Note, we are DONE with .NET Framework 3.5, so there is zero chance it is getting in that release.
From my point of view a patch as soon as possible, and have it included in the next release of the framework - Since this is a relaxation of the current restriction, I can’t see that it would cause any more problems in terms of support of existing application, as a reduction of the support incidents caused by this issue would reduce.
D) Can you ask your local network admin what they think of this issue? Would they be in favor of this sort of change? If so, when?
This change should simplify deployment - allowing Managed EXE to run from shares should mean that local disks can be more locked down as there would be no need to copy programs locally to run them.
All in all, I’m very much in favour of this change - It will level the playing field, give a more consistent user experience, and reduce the problems people have with winforms applications.
OK, the time has come to unveil my Hack for Yahoo Hack Day. Face Ball is the ‘Crazy new game at Flickr HQ‘, and images have been popping up all over flickr as other join in. Well now, you too can join in the fun, and just like Thom Shannon, make your own Face Ball images without risk of injury or special equipment.
Flickr Face Ball is a .NET 2 Windows Forms application that allows you to select images from you Flickr photo stream by tagging them as ‘ToFaceBall’, and add one of three different face ball images to the original photo, uploading the results to your Flickr account.
So, how do you get involved in this craze:
FlickrFaceBall uses the Flickr.NET API Implementation - I have only good things to say about this library - it just works
Please Note: This program is hack quality code - It’s not been tested much, and if it breaks your computer, flickr account, or anything else, its your own responsibility.
I’ve recently returned from a long roadtrip holidays in the states, and along with a large number of souvenirs, I also returned with rather a lot of photos. Whilst on the road, I had been able to copy the photos from memory card to a laptop, and I was reviewing the photos using Picassa. Prior to leaving on my Holidays I had change camera, and my new camera had the ability to shoot in Canon CR2 RAW format. I had hardly used the new camera before leaving, and imagine my disappointment when, after the first full day of shooting I return to the hotel room and review the photos, only to find that the RAW files I have a being rendered in Picasa with a rather strange rose tint. Now I knew that while I may have been viewing San Francisco with ‘Rose tinted spectacles’ , my camera certainly did not have any such filter on it.
It turned out that this was a bug in Picasa, which had been about for a while, with no sign of a solution. For the rest of the holiday, I made sure that the camera was shooting both RAW and JPEG so I could at least review the photos each day.
Upon returning to the UK I gave Picasa another chance, and checked that I had the latest version of the product using the Check for Updates option. Nothing happened, so I (wrongly) assumed that I had the latest version. A little more reading about the problem revealed that the issue had been fixed in the latest version of Picasa, and upon checking the version number of my Picasa installation, the one mentioned in the Google Groups message, and the one for the latest version on the Picasa website, I discovered a discrepancy.
One final Check for Update followed, to no avail, and I resorted to manually downloading the installer and installing over the top of my current install.
The update resolved my problem, and I could see the fantastic difference between the RAW versions and the in camera JPEG versions. It also taught me two lessions: