Saturday, October 10, 2009

Development Tools Mash Up

UPDATE: I've moved this list over to my web site. Go there to see the updated list.

This is my growing list of tools that I'm using or have used in the past. Hopefully, you'll enjoy the list and check one or two of them out.

Windows 7 Utilities
Microsoft Web Developer
  • MetaEdit 2.2 --- Allows you to view and edit IIS metabase 3.0, 4.0, and (not supported) 5.0/6.0.
UML Tools
  • TopCoder UML Tool --- An UML Tool that's pretty and free. I love using it to think through the architectural design of an application.
Programmer Fonts

  • Proggy Clean -- Compact programmer font; I appreciate its presentation and have used it a lot in the past.
  • Consolas -- Microsoft font; I'm currently using this one to constrast against Proggy Clean.

Source Control
  • VisualSVN Server --- SubVersion Server provides an easy way to create and maintain SubVersion repositories. I'm using it at home and love it.
  • TortioseSVN --- A SubVersion client; most notably known for its Windows Explorer integration. It's the best SubVersion client I've used to date. (I've tried a handful.)

Here's a short list of other developers who have lists of their favorite development tools:

Saturday, October 3, 2009

ASP.NET Membership and Profile Mismatch ApplicationId

I've been wading through the Membership and Profile features built-in to ASP.NET. In doing so, I ran into a little nasty (yet avoidable) issue. If you override the AspNetMembershipProvider and set the ApplicationName, but don't override the AspNetProfileProvider then the Profile and Membership data will mis-match as the ApplicationId will be different. The gotcha is that it will not error out. You will just see data start being generated for two different applications in the database.

In my instance, I had set the Membership provider to ApplicationName = "foo", so the Membership data in aspnet_Users was properly linking to my ApplicationName set. Unfortunately, I did not setup the same setting for Profile data. This meant that every time I manipulated the Profile data it ended up setting up a new ApplicationName = "/" and storing all data to that application. The Profile feature is smart enough to create the user for the data, so it'll additionally duplicate the user.

I wish that there was a clearer way to identify and avoid this issue for first timers to the data. My issue was compounded by the code that I was using below to setup the default Profile data to include the UserId. (This provides the cleanest way I have found to date to use the LinqDataSource without much code by using the asp:ProfileParameter.) See code snippets below for examples.