I had a particularly vexing problem that took nearly a half a day to dig to the bottom of. I was successfully able to connect to a streaming API using Adobe’s URLStream class, and I could see the passing of packets back-and-forth between the client app and the remote server using WireShark. So, there was definitely a valid connection and hand-shaking happening in the background. And, another key piece to the puzzle was the app ran just fine as a Flex app using the default bin-debug run-time settings. But, other than that running it as an AIR app or a Flex app from IIS, I simply couldn’t get any of the URLStream event listeners to acknowledge any type of connection whatsoever.
I knew this was a permissions issue, but finding documentation on AIR and Flash runtime permissions is, well, not easy. So, after quite a few searches on the internet and many dead-ends, there buried deep in some ancient scrolls of Adobe documentation were a few articles that provided the key to finally unlock the treasure chest.
You may have never heard about it before, but there is a User Flash Player Trust directory that typically contains at least one configuration file. And, in those files you can specifically grant application access to a particularly directory. In theory, there is also a Global Flash Player Trust directory. I originally thought I made the changes to that, but actually I never was able to locate it, and I ran out of time anyway. So, if someone knows where that is on Windows 7 please let me know.
I added the pathname to the AIR executable installation directory to the air.1.0.trust.cfg file and bingo the application worked as expected.
The file typically resides in a path that looks like this: C:\Users\<username>\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust
And, I add the following line to the file: C:\Program Files (x86)\BasicStreams.
[Flash Player] Administrator Controls
[Flash Player] User Control document
Adobe Online Doc – Restricting Network APIs
If you simply copy your Visual Studio 2010 generic handler (.ashx) project’s directory into a virtual directory on IIS it will fail with an error similar to the following:
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not create type ‘HealthCheck.health’.
There are lots of suggestions on the internet, but the most fundamental fix is hard to find. I know because I’ve run into this problem before and it took me quite a while to figure it out. This time I only wasted a half-an-hour before a little voice in my head reminded me that generic handlers created in Visual Studio 2010 require that they be run as an application in IIS.
So here’s how you do set up IIS to run the .ashx file as an application:
- Open Internet Information Services (IIS) Manager
- Double-click on “Application Pools”. If your Default App Pool is not set to v4.0 then double click on it and change the version. If you don’t have v4.0 installed, then you’ll you need to do so. NOTE: if you change this be sure to test your other/older applications to make sure they don’t break. If they do break other apps, then right click below the Application Pool table and create a new, custom app pool using .NET v4.0.
- Right click “Default Web Site”
- Select “Add Application”
- Fill in all the Alias and Physical Path fields. BE SURE to select the correct application pool referenced in step 2!!
- Here’ s a great blog post on how find your .NET version that’s being used: http://www.walkernews.net/2008/05/16/how-to-check-net-framework-version-installed/ .
- You can also look at the bottom of the Parser Error Message and you’ll see the .NET version there, as well.