Unfortunately I don't have time to go through and figure out why the Always Visible control wont work with a user control. Although I assume it has something to do with the HTML DOM. Some relationship in there is probably hard coded or assumed.

Here's what I was trying to do:

I want to have an always visible control that had some items in it (lets say a bunch of links). I wanted that to be in a user control. I wanted that user control to be the "always visible" control. So I set the TargetID to the user control and ... NO DICE. Doesn't work. I get a cannot load behavior ID or something like that. Its a JavaScript error, and I could figure it out if I had time, but unfortunately the project I'm on doesn't permit.

I even attempted to get around this by putting all of the ASP.NET AJAX into a user control and then add the user control to the page. NOPE, didn't work.

Solution

This is kind of a hacky solution, but it works. You can get this to work by putting all of your controls into a user control. Then wrap your user control in a panel. Like so:

<ajaxToolkit:AlwaysVisibleControlExtender
    ID="avce" runat="server"
    VerticalSide="bottom"
    TargetControlID="scrollingPanel"
    VerticalOffset="10"
    HorizontalSide="Right"
    HorizontalOffset="10"
    ScrollEffectDuration=".1" />
<asp:Panel runat="server" ID="scrollingPanel">
    <uc1:MyUserControl ID="myUc" runat="server"  />
</asp:Panel>

This will allow you to still use a user control, but in my opinion, its kind of hacky. If and when I find time to work around this I'll post an update. If anyone else knows of a fix, please let me know.

I recently had a problem that plagued me the last couple of weeks.

Problem: When I pressed F5 or CTRL + F5 or even "View in Browser" from Visual Studio (in an ASP.NET project) Internet Explorer would load. If I had any breakpoints set, the debugger would break, and then I could continue after debugging (or, if I didn't debug the project would continue to load as normal -- in Internet Explorer). Once the project continued to load in Internet Explorer (IE), IE would HANG.

I'm not talking a 5-10 second load. I'm talking 2-3 minutes!! After the initial load, the application would load as expected. I could hit refresh, everything and it would load as expected. Unfortunately this isn't a feasible solution when I need to debug on a normal basis and I cannot be waiting 2-3 minutes for the debugger to start.

The weird about this is... if I opened IE and went to ANY WEBSITE the site would load instantly. The problem was only with ASP.NET projects, making me thing it had to do with the local cassini web server.

Resolution: After some reading, I came to the conclusion that it could be related to a proxy server. I took a look, NOPE, no proxy server here. So then I started poking around with the system. There were no event logs for anything relating browser or .NET issues. I could not find anything related to this issue, other than a couple people having the SAME exact problem.

On a fluke I decided to hit F5, and then while the enormous load time was taking place I started FireFox. I copied the URL from IE (which looked something like: http://localhost:49696/default.aspx) and then posted it into the address bar of FireFox and hit Enter. To my amazement, the page loaded immediately. But  IE was still hanging, and waiting.

After changing some settings in the Internet Options panel of IE I decided to reset IE's settings (see below).

After resetting everything, everything started working again. I'm not sure what setting had started this behavior, but I do know that something in my Internet Settings got changed. Over the next week I'm going to attempt to recreate the issue, and if I'm able to, I'll post the solution here.

But if you're having this same problem, reset your settings in IE!

I was perusing the HTML 5 Spec and I ran across the HTML 5 differences from HTML 4.

There are a couple things that caught my eye immediately: new input types, datagrid, datalist, and also how the structure of the div element has changed. The thing that really sparked my interest was the input types.

HTML 5 is proposing that we have the following new input types:

• datetime
• datetime-local
• date
• month
• week
• time
• number
• range
• email
• url

In short, the user agent (in this case, the browser) will be responsible for providing the interface to which we can use the said input types. Therefore Internet Explorer, Fire Fox, Safari, etc will be responsible for rendering the UI for the input type that you choose.

Say wha?!? Yeah, finally, no more writing ajax controls for basic UI, and hopefully there is some type of validation built into the spec (but I haven't gotten that far into reading it).

Links for ya'll:

HTML 5 Spec

HTML 5 Differences from HTML 4

Jeremy D. Miller has a great post on keeping source code where it belongs. The thought process behind this is that code should be where YOU would assume it would be. If its data access code, it should be in a project/namespace that is something like Data Access or DAL or Data or something that represents the lower layer of the architecture. If its the business rules/tasks the files should be in a project called Business Rules, or BLL, or Tasks, or something similar. It makes sense, just think about this -- if you walk into a business and are given a project that was created by another developer and you're getting a ADO.NET Exception, you'd expect to find the code Data Access code in a Data Access layer, NOT in the code behind. I should not have to hunt down where you put your data access code.

We're talking about basic separation of concerns. The thing is, many developers lack these concepts because they're under the assumption of "I can write this the correct way, and it will take me 2 weeks, or I can do it quickly and it will take me 2 days." This may not matter when the application is running for a few months, but when you are asked to change the data provider from SQL Server to Oracle, or remove the web service calls and replace them with RPC calls, you're going to find yourself in a world of hurt because you didn't set everything up correctly. At this point they have amounted a large amount of Technical Debt.

He also noted that a large number of people were now using Ruby On Rails (RoR) as their development platform and I won't deny that I also believe that Ruby/Rails is huge right now. Tons of shops are running RoR and even Martin Fowler said on Hansel Minutes that ThoughtWorks was doing about 40% (or more) of their business with Ruby. The key point Jeremy brought up is that "RoR forces web developers into a bit of a straight jacket, but that's a good thing in a way." I completely agree. RoR enforces a consistent source code tree layout which allows for developers to easily find there way around a project. "Developer A" can create a project with RoR and then "Developer B" can come along and take a look at it and be familiar with the code layout and structure. The RoR community has agreed that this is the basic way to organize a project and it seems to be working for them.

So what about .NET? Enter Tree Surgeon. Right now, its a stand alone application, but in its near future it should be implemented as a template in Visual Studio 2005/2008. So what is it? It's a application that will create that straight jacket that Jeremy spoke of. It gives the developer a basic set up of layers, unit tests, code coverage and build script. It builds the entire source code directory and allows you to build on top of it. The source code layout follows a white paper written by Mike Roberts. I've been using it for quite awhile and I'm one of the developers on the project. I recently updated the source to allow creation of Visual Studio 2005 projects. Please note, this is only on the source and has not been reflected on the production release. Download the source, run it and then choose a application name, and generate the project source directory tree. Open the solution file and your application is ready to go.

The best part is that its easy to integrate existing projects into this format. I've done it quite a few times to allow for easy integration into my clients CI environment.

If you have any requests for Tree Surgeon, please visit the Issue Tracker page and submit and issue.

Enjoy!

Over the weekend I had the time to work with Teamprise Explorer and Visual Studio Team Explorer while working on an open source project that I'm a part of. This was the first time I've worked with Teamprise explorer and Visual Studio Team Explorer. Since Codeplex houses its source on Team Foundation Server (TFS) I was required to use one of these options. This is a little look into my experience.

First off let me start by saying that I'm a Subversion junkie. I keep all of my own personal source code in Subversion and I've helped many clients implement Subversion in my time. I'm an avid user of TortoiseSVN because of its ease of use within Windows Explorer. Working with TFS was very similar to that of Subversion but the terminology was different and in my opinion Teamprise was a little more difficult to use. I originally wanted to use the Visual Studio Plug-in but I didn't want to wait for the 246 MB file to download so I could install a plug-in. :\ Therefore, I went with Teamprise first. They will give you a free license to work with Codeplex if you're working on a project, so that was a win/win for me.

Teamprise Explorer Client will allow you to connect to a Team Foundation Server to access source code (its user interface reminds of me of WinCvs quite a bit, yet  a lot more polished than that of WinCvs). The only problem that I had with Teamprise is that when I went needed to edit the code I had to "Checkout for Edit". If I did this on the entire directory tree such as my "src" directory it would log everything in edit mode. Therefore, when I went to upload the changes the entire source tree was being uploaded. NO BUENO. I know that on average I like to see what I've edited (yes, I'm used to TortoiseSVN) in some type of explorer window. This didn't happen on Teamprise (maybe there is a way to see if a file has changed other than the Pending Changes window, if so, someone please let me know). In the end, I got frustrated, ended up clicking some button on Teamprise explorer and overwrote all my changes somehow. THAT SUCKS. I got frustrated and decided to download the plug-in and start working that way.

Visual Studio Team Explorer Plug-in was great. Its interface reminded me of the old days when I use to personally use Source Safe 6.0. The icons were similar and it was familiar ground. I think we may have a winner. After making my changes again I was able to easily see what changed through simple icon's changing colors and I checked everything in really easily. It was very seamless. The only downside to Visual Studio Team Explorer is the install process. First you have download an IMG file, then download an install an IMG extractor and then open the IMG, then install. Only then did I get the full Visual Studio Integration. Very nice.

One downside that I see is that the Express SKU's don't allow plug-ins so this kind of sucks for those guys. How can you have an open source hosting site that doesn't allow its users to easily get the source. Don't get me wrong, they can use Teamprise but they have to know there is a learning curve with that. I didn't have the patience for it this time around.

There is hope on the horizon though...

CodePlex will be offering TortoiseSVN Support to Team Foundation Server. Therefore you will be able to use a tool such as TortoiseSVN to access Team Foundation Server. Supposedly this is to be released on or around June 18th of this month. In a nutshell there will be a bridge built between SVN Commands and TFS commands. I would assume this is a good place for the Adapter pattern to be put to work.

Hopefully this comes to fruition, I can see a lot of people possibly moving their projects to CodePlex if that's the case.