Wednesday, March 28, 2007

Getting IIS/ASP.NET back to the default forms authentication can be difficult. A small mistake is hard to find. I am writing this mainly so I can go back and look at it next time I have trouble.

1. Be sure the web site exists, and is configured to the correct directory.
2. On directory security, be sure anonymous access is checked, that user name is set to the default, with Allow IIS to control password checked.
3. Be sure integrated windows authentication is checked.
4. Be sure nothing else is checked.
5. Check the web.config, and be sure it looks something like.

<authentication mode="Forms">
<forms path="/" name="CookieName" loginurl="login.aspx"><authentication mode="Forms">
<forms loginurl="login.aspx" name="CookieName" path="/"></forms>
<deny users="?">
<allow users="*">
</authorization><allow users="*">

Thursday, March 15, 2007

Object synchronization method was called from an unsynchronized block of code

Despite the tremendous improvement in .NET compared to anything Microsoft released earlier, Microsoft still lags behind where Java was with ease of use of multithreading. .NET multithreading is great and easy to use - but only if you already know multithreading. There are hundreds of different ways to handle synchronization, and some work well, some work poorly, and in my opinion, some don't work at all. All this makes me wish they would just give me Dijkstra's semaphore (P and V methods) and let me build my own stuff on top of it.

Today, I tried to Google an error I got: "System.ApplicationException: Object synchronization method was called from an unsynchronized block of code." Immediately (based on the error message), I thought I either needed to mark the method, class or assembly as needing to use synchronization somehow (either attributes or compiler switches came to mind). This was odd, because I didn't remember ever needing to do this before (well, not since the COM apartment threading mess anyway).

You would think this would be easy to find. I went through every entry on the first 3 Google pages (60 entries). Lots of people had this problem, but most answers were:
  • use Monitors instead of synchronization object X-with no explanation of why.
  • Do you really need to do this? - I always hate this answer when someone posts a legitimate technical question. The question still has merit, regardless of whether the author really the answer or not.
  • Use Google to find the answer - I hate this too. I am convinced it will eventually destroy Google (any search will eventually only yield thousands of pages telling you to search Google).

Anyhow, I gave up on Google and went back to my code, and the answer was really simple. All I did was release the Mutex before I acquired it (I left out the line of code Mutex.WaitOne).

I guess I am posting this for 2 reasons

  • I don't want anyone else looking through 60 pages of worthless Googling (although I doubt this blog will get ranked in the top 60 anyway).
  • This is a really bad error message. Every time you enter a synchronized block of code, you do so by calling an object synchronization method from an unsynchronized block of code. What it should say is "Invalid Object synchronization method called from an unsynchronized block of code" or simply "Invalid Object synchronization method call". This would make finding the answer easy.

Wednesday, March 07, 2007


I have been thinking about software architects lately. Some, if not most, companies hate to see 'software architect' on a resume, and don't want to hire anyone into that role. My last employer (not my current) always said they wanted me to step up to that role, but also that customers don't pay for architecture, and it is not very important.

Nothing could be farther from the truth. Customers pay big for architecture, but they don't pay for good architecture, they pay for bad architecture. If everything is architected well (like my current job), existing code rarely needs changed, and most new development involves thinking about what the product should do and how it should do it. If everything is architected poorly, all the time is spent fixing the same problem over and over. People blame coders for lacking "attention to detail", when 2000 lines of code are used to do the job of 200. New development is slow and tedious, the "what the product should do and how it should do it" either becomes big upfront design, or becomes an afterthought. Products are released that are unsupportable, and if they crash, the only way to find out what code is at fault is by the whole development team staying hours late going through Dr. Watson logs and spaghetti code. Obviously, products developed this way are more expensive.

What some people think of as good architects are problems to. Big companies pay a few "architects" six figure salaries to sit in a private office isolated from the team, draw fancy Visio diagrams about complex "frameworks" and "reusable components", and tell coders what to code. This make projects more expensive too (although never as bad as the first scenario). These architects are probably responsible for most of the negativity people have about hiring architects. They are probably the architects Joel talked about in "Don't Let Architecture Astronauts Scare You" - although I blame salespeople for that (more on that later).

So are architects really needed? Read about the most popular real world architecture style - Big Ball of Mud. Most agile coding (Scrum, XP) seems to frown on (or ignore) architecture. It seems most of the successful projects are those that ignore architecture completely, but end up with a well enough architected code base to avoid the first scenario. But this is far from optimal, and usually happens by chance.

So what is the solution? I remember back to my days being an undergrad, and Dr Gowda's class. The most important lesson he always stressed was coupling and cohesion. This goes back to Structured Design by Larry Constantine in 1974, before I was even born. With things like "object oriented" and "agile methodologies" becoming more and more popular, no one likes the idea that the solution to most of our problems is over 30 years old. If a complicated and large system, no matter how otherwise badly designed, is loosely coupled, it can be fixed and used and maintained. Once a solutions develops bad, tight coupling system wide (to the point it cannot be decoupled), you have to throw it away, or all your efforts become more and more difficult, and eventually wasted.

I think this is largely the role of architects - to avoid excessive coupling within the system, to prevent it from degrading to this point, and to recognize if this happens. Beyond that, architects are useful to review code, ensure good programing practices are followed, and spend the rest of their time doing development. Is this is best left to one or a few team members designated as "architects" or best done by everyone? I think it is best done by everyone on the team.