Using Google Gears to find Montreal's Bus Stops

By Jay at August 31, 2008 20:08 Tags: , ,

Cet article est également disponible en francais ici.

It's been a while since I've posted on this blog. This time, I will not be talking about bluetooth, but still about some .NET powered code :)

I've been busy lately, but I've found some time to work on something that will help me a lot, and I think a lot of Windows Mobile users and mobile users in general.

Montreal's Bus network is somehow large, but its representation in the digital world is quite poor, and inexistent when talking about mobile internet. The web site in question is generating some quite large pages and is not suited for mobile web browsing.

Most of the time, you may want to know the schedule of the next bus, and this is quite hard to get this way.

There's been some effort lately to offer this kind of service on the iPhone, but I wanted to give the opportonity to other users to have the same information, with some Geo Localization features.

This is where google gears comes into action, where their latest release offers a Geo-Location API, which approximates a position using the nearest GSM cells location. Unfortunately, it only works on Windows Mobile devices. But don't worry, if you don't have a Gears enable device, it will still work ! You'll only have to type a bit, by entering your streets intersection.

After getting that location, I'm querying a database (using Linq to SQL) to get the nearest Bus Stops and their next schedule. I'm also querying Google Maps to get some markers pointing at the bus stops. That can be helpful since the Geo-Location is only an approximation by nature, because of the GSM 'triangulation'. It can also be used to query the schedule of a specific bus stop, using the number placed at the bottom of the bus stop signs. A small plus here, compared to the original site, is that schedules from the past half hour are still visible, making possible to have determine if a bus has missed its schedule using a great long street.

Anyway, if you're in Montreal and have an internet connected device (or a normal PC), give it a try by connecting to this adress :

Any comments or suggestions are welcome !

Prevent ASP.NET web.config inheritance, and inheritInChildApplications attribute

By Jerome at March 23, 2008 12:34 Tags: , ,

Since I've changed my top level blog engine, I've had some troubles with YAF, the forum engine I'm using for my Remote Control software.

The forum I'm using is in a child directory, which is a child application defined in IIS as an other application. The BlogEngine.NET disables the use of Sessions, and YAF requires sessions to be enabled, plus BlogEngine.NET adds some custom HTTP handlers, which incidentally are not known but the forum application. This is quite a mess, and to be able to get both applications running without fine tuning each one to work with the other, I had to use the little known attribute inheritInChildApplications.

This attribute prevents an application from passing its configuration as a default to child applications. Using this attribute is a little tricky, and has to be used this way :

<!-- Root web.config file -->

<?xml version="1.0"?>


  <location path="." inheritInChildApplications="false">


      <compilation debug="false" />

      <!-- other configuration attributes -->




This way, any child application defined below this application will not use the current configuration. There's some mystery around the inheritInChildApplications attribute; it is not defined in the dotnetconfig.xsd file and it still is a rather helpful configuration option...

IIS, HTTP 401.3 and ASP.NET directories ACLs

By Jerome at September 01, 2006 22:09 Tags: , ,

A few days ago, on a newly installed web server with all the appropriate security patches applied, I kept having the same error on every ASP.NET 1.1 application I was running :

HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource.

At first, the reflex is to check all the permissions of the mapped physical directory, that they match the Application Pool identity, the guest identity (IUSR_Machine on my server) and for some configurations, the impersonated identity any ASP.NET configuration. Even with all these checks, any ASP.NET application was returning the same 401.3 error for anonymous users...

Well, it turns out that the ACL of the %SystemRoot%\Microsoft.NET\Framework\v1.1.4322 is important too... I don't know how the ACL got changed in the first place, and I don't know either how I came to check on these ACL, but that can waste a lot of time...

ASP.NET Remote Debugging, Windows XP SP2 and .NET Framework 2.0

By Jerome at December 13, 2004 11:38 Tags: ,

I did not have to create and debug any ASP.NET application for a long time, but since I'm creating an online Questions/Answers application, I had to use the really nice debugging features brought by Visual Studio .NET.

To be specific, I did not have to debug any remote web site since I installed the Windows XP SP2. My configuration is quite simple, I host my application on a development Windows 2003 Server and I design with VS.NET on my Windows XP machine.

So when I trying to debug my web application, all I could get was : "Unable to debug the application" or "The remote debugger could not connect to the local machine" or a really helpfull "Cannot debug process".

The first reaction when seeing things like this is to check the local and remote VS Developers and Debugger Users security groups. But every thing was fine there... In fact, the problem lies in the DCOM security configuration. Installing the SP2 removed the right for the anonymous account to use DCOM remotely... but not for the Everyone account. Odd.
The only thing to do is to get there : Run / dcomcnfg.exe / Component Services / Computers / My Computer / Properties / COM Security / Edit Limits, and to check "Remote Access / Allow". Easy.

This solved my first problem, the remote debugging. The second one is still ASP.NET debugging, but locally this time.

I have both VS.NET 2003 and 2005 installed on my local machine, and so are both 1.1 and 2.0 .NET Framework versions. Installing 2.0 over 1.1 changes the default framework used by the Windows XP IIS to version 2.0 which breaks the 1.1 debugger :)
The simple thing to do here is this : IIS / Web Sites / [WebSite] / Properties / ASP.NET, then select 1.1.4322 for the ASP.NET Version field and that's it :)

Man, I really like being able to debug my Web Applications, I really missed it ! (And so was Karouman actually, who was debugging blindly by guessing exceptions :p)

About me

My name is Jerome Laban, I am a Software Architect, C# MVP and .NET enthustiast from Montréal, QC. You will find my blog on this site, where I'm adding my thoughts on current events, or the things I'm working on, such as the Remote Control for Windows Phone.