Shoutout - Using SVN for your C# .NET project

If you want to use Subversion(SVN) as source control for a C# .NET project, there are two issues you'll run into: the generated ".svn" subdirectories (which are incompatible with ASP.NET projects), and the various C# binary build artifacts that you'd want to keep out of a repository.

For issue one, SVN now supports an environment variable called SVN_ASP_DOT_NET_HACK. Setting this to any non-null value will make your SVN client use "_svn" subdirectories instead of ".svn" ones. Note that you won't be able to use any source trees you checked out before setting the variable, so you should commit all changes, blow away your current source trees, set the variable, and then check out the trees again. The description of this in the official SVN documentation is here.

For issue two, see this post. The author of this guide explains how to set your SVN project to ignore VS project binaries and directories (the /bin/* directories, .suo files, etc.) It would have been a perfect shoutout if they'd linked to the "_svn" hack instead of just mentioning it.

There are lots of reasons to use SVN instead of Visual SourceSafe, so I won't bother listing them.

Citation: SVN Documentation
Citation: Slashdotdash

Shoutout - JUnit 4 Tutorial and TestNG Comparison

I guess I've been living under the proverbial rock for the past two years because I didn't know about JUnit 4.x till yesterday. If you already know JUnit 3.8.x and are an intermediate or above developer, the best tutorial is cited below.

JUnit 4.x is definitely better than its predecessor, but then again there's also TestNG. I've cited a comparison between the two that favors TestNG.

Citation: DevX.com tutorial on JUnit 4 by Antonio Goncalves
Citation: IBM DeveloperWorks article on JUnit 4 vs. TestNG

C# MVP For You and Me - Part 2 - Jeremy D. Miller Leads Me Out of the Wilderness

Patterns are necessary for any maintainable, testable, well-architected GUI. This is especially true for a C# WinForms GUI, for all the reasons discussed in the previous series post.

Even Microsoft itself realized this and has, over the years, promoted a succession of pattern sets for .NET GUIs. These include the Composite UI Application Block (CAB), the Smart Client Software Factory, something called Acropolis, and finally something else called Prism. All but Prism appear defunct, and Prism seems geared primarily toward WPF, which I am not using (see previous series post.) More importantly, all including Prism are tremendously complex. Each one is a skill set in itself, like learning a whole new language. They're better than the Visual Studio approach of automatically generating two-tiered client/server apps, but are overkill for small projects like mine.

The .NET developer Jeremy D. Miller would agree with me. He wrote a series of blog posts, Build Your Own CAB, that describe a light-weight methodology for architecting C# WinForms GUIs. This methodology has enough structure to alleviate the dangers and shortcomings of the VS code generation approach, but is not so complex that people write books, teach training courses, and hold conventions to discuss it.

Miller's methodology is based on the Model-View-Presenter (MVP) pattern. MVP is kind of like the classic Model-View-Controller (MVC) pattern. The differences are so subtle that I will avoid discussing them. If you like, you can read about them here.

Once I finished reading the Build Your Own CAB series, I built the first screens of my app in a matter of days, and had an architecture that continues to carry me forward today. The screens more than met the standards I had set for myself. The code was testable, maintainable, and readable. There was not a line of business logic or service layer access in the actual GUI code. Miller helped me reach my main goal - that a brand new team member could read my code and understand it within minutes.

What I will describe in the next post is partly a summary of Miller's approach, and partly a description of how I implemented it. I have made additions and changes to his methodology, and I will state clearly where I've done so. No matter what you get from my reports, I strongly encourage you to read Jeremy's entire series. It has become my bible of .NET GUI development. Jeremy is a very smart and practical software engineer. I wrote my project based on his work, and will continue to do so until I switch to WPF. Once again, the link to his excellent series is here.

Shoutouts - First Edition

I'm taking a quick break from the MVP series to post my first edition of "Shoutouts." This series aims to acknowledge, summarize, and cite technical blog posts that have helped me solve extremely specific low-level tech problems. With the right descriptive keywords, I hope to make it that much easier for you to Google these than it was for me.

---

Posting Source Code on Blogger, Especially XML
A meta-Shoutout: the post you are now reading would not be possible without this guy's help.

Citation: Please Make A Note

---

Spring Web Services - Generating WSDL
To get the WSDL generator to include the hostname and full URL in your <soap:address location="">, add this to your web.xml file:

<init-param>
<param-name>transformWsdlLocations</param-name>
<param-value>true</param-value>
</init-param>

This tidbit was missing from the Spring WS Tutorial, and it cost me half a day. I don't know why transformWsdlLocations=true isn't just the default setting when configuring the dispatcher servlet, and I made this known in a comment to the cited blog replete with late-night histrionics.

Citation: Phill's J2EE Blog
Also: Mike's Blog

---

Spring Web Servies - AbstractStaxStreamPayloadEndpoint Sample
This is the only sample code I found for the AbstractStaxStreamPayloadEndpoint. There isn't even an example in the actual Spring-WS distribution. Using STAX is crucial for dealing with large XML requests and replies. You want to stream things whenever possible, rather than materializing giant DOMs.

Citation: Pascal's Blog

---

Tomcat, Log4J, Spring - Error: java.lang.IllegalStateException: Web app root system property already set to different value
It's quite likely that you'll use these three frameworks together. It's also quite likely you'll get this error message if you do. To fix it, add this to your web.xml:

<context-param>
<param-name>webAppRootKey</param-name>
<param-value>uniqueAppRootNamee</param-value>
</context-param>

To find out why, read the citation. It's Tomcat's fault. I love Tomcat but there is no earthly reason why this had to happen.

Citation: Glennn's Stuff

---

Maven Profile Activation
Discussion of the subtleties of Maven profile activation, including what <activeByDefault> really means. The word "subtleties" and the words "Maven profile activation" do not belong in the same sentence. This has made me want to back off of my use of Maven profiles, and I'm posting a comment to the cited blog asking what alternatives I can use to accomplish what I want.

Citation: James Lorenzen's Blog

---

Maven Jetty Plugin Configuration
The Maven Jetty Plugin saves tons of time when doing web app development. Unfortunately, its documentation page is incomplete, and does not fully specify how to change things as basic as the port number. Luckily, I found a blog post that does - see the citation.

Citation: aminal

C# MVP For You and Me - Part 1 - Intro

This post is the first in a series about technology choices and patterns I used to build a C# rich client GUI. It's written from the perspective of an experienced Java developer who, three weeks ago, had never worked in C# or .NET. Learning the language was easy but learning the UI toolkits and best practices was hard, and thus worth writing about and sharing. I especially hope that the patterns piece will be helpful to the reader.

In this post I talk about the UI toolkits and the need for design patterns. In the next post I'll talk about actual patterns, and how I came to understand a way of using a lightweight model-view-presenter (MVP) pattern implementation to get the job done.

• C# Rich Client Libraries - there are two: WinForms (old) and Windows Presentation Foundation (WPF - New). I chose WinForms because WPF is still only a few years old, and the WPF datagrid widget is only three months old. Also, people have been complaining about font blurriness in WPF - here is a post showing MSDN comments spanning two years on the issue, which is still unresolved. WPF is definitely prettier and is faster if you have the right graphics card. In terms of architecture and implementation, it is completely in tune with modern UI trends, enforcing separation of data from presentation and featuring a declarative UI definition language. WPF is the future, but WinForms' reliable nearly 10-year old datagrid was the route to take for this project. I refuse to be the guy who tells the traders they're losing millions of dollars because of "a bug in the rendering toolkit." Still I'm encouraged by WPF and look forward to revisiting it next year. Here is one of the more thoughtful articles I've read on WinForms vs. WPF.


• The Need For Patterns - C# 3.0, the MS Visual Studio 2008 toolset, and the Microsoft databinding API make it shockingly simple to build databound visual apps. In his comprehensive and thoughtful book, Data Binding in Windows Forms 2.0, author Brian Noyes starts chapter 1 with a demo of that very capability. In minutes, he walks you through steps that generate a fully-functional custom GUI for browsing a database. This is light-years ahead of Java Swing and the dev tools that go with it. Writes Noyes at the end of the demo: "If you aren't saying 'Wow!', then you are either really hard to impress or you haven't spent much time trying to write applications like this." I was saying "wow!"
  
  I was also saying "uh oh," because what the tool clearly built was a classic two-tiered app with the GUI wired directly into the database, with data access code sitting directly inside the GUI widgets. It was essentially VB/Access, only in C#. Architecture 101 tells us this is bad, for all the standard reasons: it's unscalable (hitting the database directly, not through connection-pooling middleware), unmaintainable (every user's UI code breaks if the database schema should change; spaghetti data access code is repetititously scattered throughout the presentation layer; architecture is essentially non-existent), and untestable (short of visually testing everything by hand.)
  
  At the end of the chapter, Noyes himself says "uh oh":
  
  

  The thing you need to realize is that Visual Studio capabilities have the potential to encourage you to employ bad design practices. As you saw in the walkthrough example earlier in this chapter, there is a rich data-binding experience in Visual Studio within a Windows Forms application if you pull the database information directly into your Windows Forms project, create a typed data set and its associated data adapters in the project, and then set up the data binding based on the data sources that result. However, if you follow that pattern, you are putting data access code directly in your Windows Forms project, which is exactly what you shouldn't do . . . So even though you will see a lot of demos that do this—and I even do it in some places in the book to simplify the samples . . . you shouldn't plan on doing this in production applications.

  His book has some good examples of patterns, but focuses more on databinding itself, since that's the title of the book.
  

There was clearly more power here than in any tools I'd used before. There was also a great potential for misuse. I wanted to bring my Java experience of UI design patterns to bear on the project, but I was uncertain and unsure because the C# language, API, and overall developer lore were still so new to me. I did a bunch of research using Noyes as a starting point. It worked out really well and I'll share the summary in my next post.

First

Welcome to my blog. In this and in all other posts, I will be short and simple. That may sound funny as the salutatory note to a body of writing whose very existence is optional. Shouldn't the ultimate in blog brevity be no blog at all?

Yet there are things that I want to say and share, so there will be a blog and now there is one. My promise is to not waste your time. You will know what a post is about within one sentence of its beginning. Every post will really be about the stated topic. So will every sentence in each post. I will strive to not ramble. I will keep myself out of the post, unless the topic is myself. I intend to keep posts of the latter category to a minimum. If that doesn't work out, I'll start a different blog and move those posts there.

I will be writing about software development, finance, life in NYC, politics, literature, games, and culture. Food, drink, and music may also find their way inside (edited on 4/26/2009 to reflect reality). You are free to read, skip, comment, link, subscribe, syndicate, consume, and digest.