MPLS ALT .NET

Yesterday was the first ever MPLS ALT.NET get together at the Bulldog N.E Thanks Ira Mitchell and Jim Swanson for hosting. Judging by the turnout at the initial meet one can easily tell that there is a great enthusiasm for alt .net in Minneapolis.

Jim and Ira do a better job of explaining What ALT .NET is all about.

The folks at Redmond, WA do a great job trying to build awesome tools for developers but often times committing resources to every available tool in the open source community is not possible. Filling this gap is where a community like ALT .NET can help.

The state of Microsoft and the OSS community is better explained by Ayende Rahien.

I hope that this community becomes successful and brings in the best of the OSS, Java and RoR communities into the .NET world.

If you are using Fiddler 2 follow the instructions in the Fiddler FAQ

Why don’t I see traffic sent to http://localhost or http://127.0.0.1?

Fiddler does not capture packets sent to the localhost URL which makes debugging web applications hosted in your local machine painful.

Here is how I configured Fiddler to debug web applications hosted in your local machine,

Lets say your application is accessed using the URL http://localhost:8090/MySpiffyApp/default.aspx. To make fiddler capture the HTTP requests sent to this URL, all you have to do is edit the HKCU\Software\Microsoft\Fiddler\ReverseProxyForPort and set the decimal value to 8090. This tells fiddler to proxy all traffic sent to HTTP port 8888 (default proxy port) to HTTP port 8090. Now access the application using the fiddler proxy port

http://localhost:8888/MySpiffyApp/default.aspx

and you should be able to see the packet trace in Fiddler.

If you see the page below instead of your application then try restarting Fiddler and make sure the registry key name matches exactly as above.

1. Set the HKCU\Software\Microsoft\Fiddler\ReverseProxyForPort registry DWORD to the local port you’d like to route inbound traffic to
2. Restart Fiddler

Let me know if this didn’t work for you or if you have another way of debugging web applications hosted on your local machine.

The launch press release is very promising.

This deserves more than just a press release. I will update this post with more details, especially how it relates to VMWare’s technology.

There was a pleasant surprise for me last week when I discovered that Microsoft had come out with a beta version of an Architecture Journal Reader

It is a .NET 3.0 desktop application that is built using WPF . Here is a brief description of the application from the application download page,

“Demonstrating many of the UX principles highlighted in recent issues, this new reader is a locally installed application that enables you to take every issue of the Journal into a searchable, immersive, and easy-to-read experience. The application synchronizes with our content management services so that you’ll automatically have access to the latest Journal issues without needing to download PDF files or checking online.”

The Architecture Journal as you know is a magazine and the Journal Reader application essentially gives you all the Journal content in a digital format right on your desktop without some of the usual browser annoyances. Its goal is to improve the overall user experience of the magazine reader.

Here is a sample screenshot of the Front Page,

Apparently, A lot of publishers have adopted this technology and have implemented news readers using “a news reader SDK”.

I haven’t tried any of these readers yet but the idea is certainly catchy. I for one have always enjoyed a cup of coffee and a newspaper without being distracted on weekend mornings.