Enterprise Web Framework talk at WNYDNUG

On August 20th, I gave a talk at WNYDNUG on the Enterprise Web Framework. The slides are available here.

Western NY .NET User Group kick off

On February 20th, I will be speaking at the Western NY .NET User Group. This is the first meeting in awhile, and it should be a good time. Since they haven't heard it yet, the topic will be Automatically-Generated Data Access Layers.

VDUNY Talk

On Wednesday, October 24th I gave a talk on automatically-generated data access layers to the Visual Developers of Upstate New York group. You can download the slides and the sample solution here.

Microsoft Launch Event

Andy Beaulieu's CNY group just held a successful (as always) launch event for the new Microsoft products. I gave a talk on the new Windows Presentation Foundation, and the slides for that talk can be found here.

CNY Developer Group Talk

I recently gave a talk at the Central New York .NET Developer Group on data layers and on the benefits of code generation in general. The zip of the slides and the solution I used are available here.

If you plan to do more than just look at the existing code, I'm the first to admit that it requires some setup. Making changes and regenerating the code would require CodeSmith 2.6, SQL Server, and some configuration. In the future I plan to make instructional videos for both the use and setup of these tools. Until then, feel free to post questions.

Atlas gotchas

I recently started playing with Atlas, Microsoft's framework for AJAX-like behavior in ASP.NET web applications. First of all, the framework is great, and I've already had a lot of success applying updatePanels to existing web sites.

Let me tell you, though, about the two lines of "code" that had me debugging for 14 hours.

The first problem I encountered was autopostback drop downs doing an asynchronous postback to the server, doing the work (I could see it in the debugger), and then having the results disappear into the ether instead of showing up on the screen. The problem was totally silent and caused no run-time errors of any kind (unless you count not showing the user their data as a run-time error).

This problem was caused by a nondescript piece of html that I had never explicitly written, but was rather leftover from some sort of automatic Visual Studio 2003 template html. My .aspx page had the following line:

<meta name="vs_defaultClientScript" content="JavaScript"/>

Apparently this hijacked Atlas's script handling ability and silently squelched some sort of important behavior that resulted in the above problem. Deleting this line made the problem disappear instantly.

The second problem I had was also related to autopostback drop downs. This time it was when I put an updatePanel in a dynamically added child control. The error here was more obvious. When I changed the value of any autopostback drop down, I received a client-side popup window with the following message:

"An async postback was caused by a control within UpdatePanel '' but the panel could not be found in the page."

After several hours if experimenting with dynamically-added controls (suspecting they were to blame - they were not), I discovered the real problem. Another line of code I never explicitly wrote was breaking Atlas. This time it was in the web.config file. The line was in the portion of the web.config file and looked like this:

<xhtmlconformance mode="Legacy"/>

This beauty of backwards compatibility cost me my whole weekend. Documentation for the element/value pair states that it "Reverts a number of rendering changes made for conformance to the v1.1 rendering behavior." I suspect this line was added by the Visual Studio 2005 migration wizard. Changing the value to "Strict" or "Transitional" (or by deleting the line, which defaults to Transitional) instantly fixes everything.

"The Source Control Experience"

I've encountered a lot of puzzling and disappointing issues while using source control recently, and while I can't fully explain all of the problems I've encountered (seriously - there are inexplicable problems), I can share what I collectively dub "The Source Control Experience."

The fundamental problem with source control is that it isn't transparent enough. It tries to be, but obviously fails. Almost every operation developers perform on a daily basis becomes more complex in a source-controlled environment. This brings up one of my most-often-asked questions - "Does anyone actually use this?" (and the corollary - "How can it be this bad if people actually use this?").

The best recent example is migrating from a Visual Studio 2003 solution to a Visual Studio 2005 solution. As if that procedure weren't complicated enough on its own, enter source control (I can hear support representatives cringing when the customer says "by the way, it's in source control").

For my company and many others, the most common thing we want to do is to take a source-controlled Visual Studio 2003 solution (which contains a mixture of libraries, web projects, and setup projects) and send it through a process that results in a Visual Studio 2005 solution that contains the same projects, still functions (bonus), and is still under source control with history preserved.

It turns out that this exact scenario, which I still think must be the most common use case in the development world (excluding HappyExampleville, which may be a larger portion of the development world than I thought), is totally impossible.

After taking a moment to reflect on the five-odd years of development it took to arrive at the intersection of most-desired and impossible, let's explore why it's impossible. The most basic reason is that web projects are explicitly removed from source control during a conversion. Attempts to add it to source control in the same location it used to be in is a total disaster (do not do this). That's pretty much the end of the game right there. I ran into other problems (none of my setup projects converted properly) that I'm somewhat confident I could have found a way around had I actually tried. Since the game was over after the web project issue, I didn't even try.

SourceGear, the makers of what I feel is the highest-quality source control product available at the moment, attempted to come up with a procedure to convert to a solution to Visual Studio 2005 without losing history. They weren't able to.

The Microsoft-recommended procedure of "take it out of source control, copy it somewhere, convert, then re-add" should have provided warning. Warning maybe not of poor conversion capabilities, but warning that they don't think their users are interested in using source control, or, if they are using source control, they don't mind blowing away their history completely. By the way, have you ever tried to completely remove something from source control? Visual Studio suddenly becomes the Oracle ("Some time ago, this solution or one of its ancient ancestors used to have or know about source control bindings. Visual Studio does not know what to do, so it will silently remap some of your working folders to confuse you in the future.").

The fact that the community isn't in a giant uproar about this makes me wonder, again, if anyone actually uses source control in an actual environment to do actual work.

One small think I'd like to add is about the new Visual Studio 2005 source control API. This was supposed to be the silver bullet that saved source control. It was supposed to allow renaming, moving, deletion, and it was supposed to have much more coarse-grained communication to improve performance over WANs. It was supposed to fix every problem everyone ever complained about in source control support boards. Well, it didn't.

I have folders that check in perfectly using the standalone Vault client, but never succeed when using Visual Studio. When another developer deletes some files from a solution, my Visual Studio is smart enough to know they're gone, but not smart enough to know they were deleted (they show up in pending checkins as "Files to add" until I do a Get Latest). It also constants wants to check in PDB files, and then fails when it attempts to, and then decides it doesn't want to check them in anymore after I do a get latest (actually, my bin directory has two PDB files in source control, and the rest of the files aren't - consistent).

The most amusing (if gaping holes in software functionality can be called that) thing about the way Visual Studio 2005 handles source control is what it chooses to put in transactions and what it chooses to leave out. All checkins go in a "pending checkin" queue that gets committed as a transaction at some later time. Well, deletions don't go in that list, they happen immediately! This makes for fantastic broken builds, and leads me again to my question: How can anyone actually have used this for any period of time and thought that it worked well? Does anyone actually use this to do real work?

Anyone who uses any sort of automated daily build (CruiseControl, etc.) would have noticed this problem immediately. This leads me to believe that no, nobody does actually use this to do real work. Our software development practices are being driven exclusively by residents of HappyExampleville, and this is hugely disappointing.