Posts Tagged ‘ServerVariables’

I finally found some time to try out my preview account on Windows Azure and the new January CTP of the SDK and VS tools and thought I’d share some my impressions & some hurdles I ran into while getting up and running.

1) To debug your application locally you need to be running a local instance of IIS which I didn’t realize until trying to run my project in VS that I hadn’t actually added to Windows. I guess I’ve been so spoiled with VS.NET’s built in localhost that I didn’t have a need for a local instance of IIS until now. I remember the day when this was one of the first thing I did after installing Windows. Looks like a return to those days.

2) To run the development fabric (the thing that allows you to simulate and debug Windows Azure on your workstation), you have to run VS.NET as an administrator. So far I’ve forgotten everytime I’ve gone into my project and I’m sure it won’t be the last. It’s kind of a bummer when you launch VS, load your project hit F5 and Arg!… I have to start all over. Yes, I get impatient when it comes to repeating my own mistakes 🙂


Note: Turning of UAC does not eliminate this.

3) I ran my app locally and all I got was a blank white page instead of my SL app or an error. Fortunately I’ve ran into this more than once now on Windows Server so the problem & solution were still lingering somewhere in the back of my head: the xap mime type wasn’t added to IIS. Once I realized this, a quick search on google yielded the solution and a minute in IIS was all it took to move to the next problem…

4) Next, I added a reference to my WCF service via the ‘discover’ feature in service references and it was added as http://localhost:12404/Service1.svc. However, the Azure development fabric actually runs the app under: It only took a quick glance at my address bar in IE to discover this and realize that my service was probably running on port 81 too. Changing ServiceReferences.ClientConfig to the new service url was all it took.

5) Last, I received HTTP error 403.3 when trying to hit my local .svc file. This time I was prepared because of the “xap incident” (#3 above). Again, I needed to add a mime type for .svc files as well. As with the xap file extension problem, it only took a few seconds on google and I was up and running with the fix.

Finally, I was in business running locally and ready to deploy! I wanted to see my app and service running in the cloud… no time for reading documentation right!? Well the publish experience for Azure was made for people like me. I right clicked on my startup project and chose ‘Publish’ not entirely sure what to expect and was pleased to find the whole process very intuitive. Up came a web page to upload your package (.cspkg) and configuration (.cscfg) files to along with the folder where those two files resided.

Simply upload the two files and start your server instance (staging or production) and away you go. Publishing wasn’t quite as easy as publishing to an ftp site but I had no trouble figuring out what to do and in no time I had my app running in a staging environment and moments later running from my vanity url. Very cool! There was a little confusion for a few moments because after the management console reported my instance as “Started” it still took a minute or two before it worked in my browser. In the words of Axle Rose and Yoda, I just needed a little patience.

All in all, I was a little dissapointed with the experience in Visual Studio and worry about first impressions of those not as familiar with VS development. Then again, VS.NET 2008 was out the door long before Azure hit the scene, so I’d expect a little retro-fitting to be required to get VS to play nice with Azure and the development fabric. Hopefully in VS2010 it will all be much more integrated as ASP.NET apps are in VS today.

P.S. You can see the fruits of my labor on my previous post where I created an application to peer into Silverlight’s BrowserInfo and ASP.NET ServerVariables collection.


Read Full Post »

ASP.NET allows you to get at some great information about the client and the server via the HttpContext.Current.Request.ServerVariables collection. Likewise, Silverlight allows you to get at a few local variables of its own through the System.Windows.Browser.HtmlPage.BrowserInformation object.

But, to use these variables we often need to know what kind of values to expect. For example, let’s say you’re going to create a condition based on which browser the user is using. You would use BrowserInformation.Name. But Name is a string, not an enum. So what are the various values that can be returned by this property? This might be documented somewhere for the officialy supported browsers, but the only fool proof way is to actually try it by writing a dummy Silverlight app that spills out this variable and run it in all the different browsers to see what comes back. The same applies to ServerVariables but even more so because this is just a big dictionary so you don’t even know which variables are going to be present let alone what their values will be.

Here’s a utility I wrote for anyone to use that will help you look at all the BrowserInfo properties and ServerVariables. Hit this page from any machine to see what values it is sending up to the server. Bookmark this page, it will probalby come in handy someday when you’re scratching your head wondering what useragent you’re sending up to the server.

BrowserInfo and ServerVariables

Another cool part is that it not only shows you what servervariables are available at the time your web page is requested, but also what servervariables are available when you hit a WCF service from Silverlight. There are some subtle differences.

Also note that it’s hosted on Azure so you can also get a glimpse of which ServerVariables Azure provides access to. On first glance it looks the same as Windows Server but I haven’t done a variable by variable comparison.

Enjoy, I hope this comes in handy!

Download the source code here to see how it works or to host on your own server.

Read Full Post »