Are you looking for a strong developer/architect with a serious passion for all things technical and a unique blend of experience? If so, feel free to email me. My main focus over the past couple of years has been on things ALT.NET-ish (e.g. ASP.NET MVC, NHibernate, Spring.NET, etc.) while I have delved into a variety of other technologies as well (e.g. Mindscape LightSpeed, LINQ, Dynamic Data, Delphi, etc.). If you know of an opening - contract or full-time - please keep me in mind. I'd prefer to remain in the Milwaukee area, but occasional travel wouldn't be the end of the world.

Until the next technical post here, take care and thanks in advance.

We ran into a problem using OpenSessionInView on an IIS7 server. It turns out that when running in IIS7's new Integrated Managed Pipeline mode, we would get this error when trying to access lazy loaded objects:

Could not initialize proxy - the owning Session was closed.

For now, we just set the Managed Pipeline mode to Classic and things work fine again. When we get time, we'll be looking to try this configuration.

I've listened to podcasts from http://www.twit.tv for a while now, and have always found the shows entertaining and informative. Scott Bourne just launched Managing Your Daily Life, a blog about backups, storage, and how to manage the volume of data we all have. Hopefully we get to podcasts soon. :)

Yes, this post enters me in a contest to win a Drobo, but I like the content, too!

The first time you load an assembly of Quartz.NET jobs, it populates the database with the current trigger information (cron vs. simple, timings, etc.) that it finds in the configuration file. It appears that this information does not get updated once it's in the database. So if you want to make a change to set the trigger time to be every minute instead of the original version of "run every day at 2am", you will be waiting for a loooong time to see that trigger fire (unless you start at 1:59am :)).

Since I'm using Migrator.NET to control my database schema, I can easily drop the tables and recreate them. This isn't a big deal because once I have things tested, I won't need to change the trigger information, but it did trip me up for a bit so I thought I'd share.

I came across this exception today when inserting multiple objects through an NHibernate SessionScope:

NHibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: 0, of class: Foo.Entity.Bar
   at NHibernate.Impl.SessionImpl.DoSave(Object obj, Object id, IEntityPersister persister, Boolean useIdentityColumn, CascadingAction cascadeAction, Object anything)
   at NHibernate.Impl.SessionImpl.SaveWithGeneratedIdentifier(Object obj, CascadingAction action, Object anything)
   at NHibernate.Impl.SessionImpl.Save(Object obj)

I didn't see much out there on this, but Geoff Lane picked up on it pretty quickly. It turns out that my Bar.hbm.xml mapping file had set the id generator incorrectly to "generated", which was a problem because it was actually a MSSQL IDENTITY field. The mapping should have looked like this:

<id name="Id">
  <generator class="native" />
</id>

Luckily for me, I had run my tests by trying to insert 2 entities inside the session so the error bubbled up right away.

Yesterday, I had to upgrade from Spring.NET 1.1 to Spring.NET 1.2 in order to use Quartz.NET. After doing that, I started to get InvalidCastException errors in my unit tests that told me I couldn't convert an int to a Nullable<int>. Things like this were broken:

void TestMe(int? id) 
{ 
  // do testing here
}

// and elsewhere, we call it like this
TestMe(42);

Very strange. It turns out that this is a known (and fixed) issue due to using Nullable types through AOP. I grabbed the latest nightly build and all of the tests passed again.

However, when running, I found a breaking change in the post-1.2.0 code that I needed to correct, namely:

Overriding the SessionFactoryObjectName in web.config no longer uses Spring.Data.NHibernate.Support.OpenSessionInViewModule.SessionFactoryObjectName as the key. Now, you need to use Spring.Data.NHibernate.Support.SessionScope.SessionFactoryObjectName. e.g.

<add key="Spring.Data.NHibernate.Support.SessionScope.SessionFactoryObjectName" 
  value="NHibernateSessionFactory" /> 

Now everything is upgraded and working again.

I've been playing with ways to write a solid (and even SOLID :)) architecture with ASP.NET MVC. I started with a plain LINQ to SQL approach, and then migrated to LightSpeed, and finally ended up checking out S#arp last week. Here are my notes of pros/cons on each approach. Yes, I could (and most likely will) address some concerns by writing code for it. This is more of a laundry list of the state of things as I see them at this point in time.

LINQ to SQL

Pros

• Visual designer

Cons

• MS is talking about phasing LINQ to SQL out and forcing people towards Entity Framework. I'm pretty sick of chasing MS's data-access strategies around every year.
• LINQ to SQL mostly defaults you to a 1:1 mapping between your database and your model.
• Support for modifications to the schema sucks, to be generous.
• No UnitOfWork concept. Of course, as I prepared this blog entry, I found this article published just today, so maybe that would address this point.

LightSpeed

Pros

• Support is outstanding.
• Nightly builds are available.
• Visual designer.
• Proven patterns bundled in their core libraries (UnitOfWork, Repository, Entity, etc.).
• Picks up changes from the schema flawlessly.

Cons

• Commercial and propietary.
• Lacks quite a bit of LINQ support. For example, groupby and join are not supported. This meant that I use LINQ to SQL when I need these features. Fortunately, that's all isolated to my report module, so it's not as horrible as it could be.

S#arp

Pros

• Open Source
• Uses standard, widely adopted open source libraries: NHibernate, Windsor, etc.
• Convention over Configuration
• Scaffolding

Cons

• I'm not digging the T4 templating mechanism. They conflict with VisualSVN and Developer Express tools, and having to write a template for each and every entity is cumbersome.
• No visual designer
• No ability to import entities from an existing database. Yes, they like DDD, but in almost every project I've been a part of, the database is the thing that already exists.
• No UnitOfWork pattern (I might be able to fit code out there that does this in with S#arp). The [Transaction] attribute approach feels a bit dirty.
• The scaffolding is a bit too simple. It doesn't build up object graphs with links (for display) or SelectLists (for editing). Yes, I can add that. It probably will get that functionality at some point, too. But it doesn't do it right now.

For now, I think I'll be staying with LightSpeed, but I'll be watching S#arp very carefully.

Ages ago, I wrote about my search for a file sharing application. I eventually went with BeInSync, and used it quite a bit over the past 18 months or so. However, they haven't updated it recently, and there are problems when editing Excel spreadsheets inside the shared folder (I told BeInSync about this problem, they fixed it, and then broke it in the last release). All in all, it was just showing it's age.

Armed with a new set of fairly light requirements (Mac/Windows support, permissions, auto-sync that doesn't fail), I evaluated the space again and came out with a very positive experience of DropBox. It works very well between Mac and Windows, has an awesome web interface, and hasn't exhibited any lags or slowness. In addition, it has the ability to revert to previous versions of documents, which is a nice feature that all developers have come to appreciate.

I'd like to see a couple features in the near future (native iPhone app with support for iWork documents, ability to set your own private key), but this thing was dead simple to install and use, and has worked brilliantly for the past month with a small group of people.