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.