Heading out for SharePoint Ignite 2010. It’s a week of deep-diving into the new SharePoint product. Matter of fact I am lucky enough to be one of 150 people world-wide seeing it before it’s official unveiling in October, at the SharePoint Conference. Learn more about Ignite here.

I was working on a project the other day and I needed to migrate/convert some excellent .NET code into a T-SQL stored procedure.  Not a terribly daunting task, but a couple of speedbumps along the way.  One such speedbump came when converting some code that used DateTime.Date and DateTime.DaysInMonth methods.  I was also creating new DateTimes based on the month and year of a given DateTime to get a “first of the month” datetime.

After a litle time spent on a un-named search engine, I found some code that makes clever use of T-SQL datetime math to achieve the results I was looking for.  After some analysis, I tweaked what I found a little and ended up with what you’ll see below.

DateTime.Date

To strip out the time from a datetime, leaving it in the form ‘2009-07-07 00:00:00′, you can do something like this:

SELECT CONVERT(DATETIME, DATEDIFF(dd, 0, @date))

Now, at this point you might be asking “why does this work”?  Well, let’s take a closer look at this one from the inside out, starting with the DATEDIFF(dd, 0, @date) part.  The purpose of the DATEDIFF(datepart, startdate, enddate) function is to determine “the count (signed integer) of the specified datepart boundaries crossed between the specified startdate and enddate.”  (Yeah, that’s straight from MSDN).  So, looking at our code, what we are doing is determining the number of dateparts of type ‘dd’ (day) that have occured between ‘0′ and our date.  It helps to know that ‘0′ is the same as ‘1900-01-01 00:00:00′.  If our sample date is ‘2009-07-10 12:31:00′, then that number of days is 40002.  From there, we simply CONVERT this number back to a datetime, resulting in the desired outcome.

First of the Month

Next, we’ll take a look at a ‘first of the month’ in T-SQL.  There isn’t a .NET ‘method’, per se to do this, but by passing appropriate parameters into the DateTime constructor, you can easily get what you need.  In T-SQL we could create a new datetime by concatenating strings to achieve the same effect as a DateTime constructor, but that is messy at best.  It would be better to use something cleaner, that looks more like what we did in the previous example.  The approach on this one is actually very similar to the previous example, in that we start by using DATEDIFF to compare the date in question to the ‘0′ date.

SELECT DATEADD(mm, DATEDIFF(mm, 0, @date), 0)

Looking at this close, we see that DATEDIFF is used to determine the number of months since ‘0′.  Then DATEADD is applied to add this number of months to the ‘0′ date, which results in the first of the month.  Good Stuff.

DateTime.DaysInMonth

Moving on, let’s look at what it takes to achieve the equivalent of DateTime.DaysInMonth in T-SQL.  This one is considerably more nasty-looking, and I’ll leave it as an exercise for the reader to break it down and find out what makes it tick.  Hint: look for the previous example embedded within this one.

SELECT DATEPART(dd, DATEADD(dd, -1, DATEADD(mm, DATEDIFF(mm, 0, @date) + 1, 0)))

Wrapping it up, nice and tidy

The obvious next step, once I had these awesome snippets of T-SQL was to wrap them up into functions so that I could re-use them to my heart’s content.  Here is a chunk of T-SQL code that you can use to create the same functions, followed by a short sample of how to apply it.

create function [dbo].[dateOnly] (@datetime datetime) returns datetime
as

begin

return convert(datetime, datediff(dd, 0, @datetime))

end

go

create function [dbo].[firstOfMonth] (@datetime datetime) returns datetime
as

begin

return dateadd(m, datediff(mm, 0, @dateTime), 0)

end

go

create function [dbo].[daysInMonth] (@dateTime datetime) returns int
as

begin

return datepart(dd, dateadd(dd, -1, dateadd(m, datediff(mm, 0, @dateTime) + 1, 0)))

end

go

declare @myDate datetime
set @myDate = ‘2009-07-04 15:34:59′

select dbo.daysInMonth(@myDate)

On Thursday, I joined my illustrious colleagues Jason and Tahmoures in presenting various aspects of Microsoft’s Team System to our development team at our monthly meeting.  Following a rousing offering from Tahmoures on Team Projects and Jason’s handy exhibition of Version Control features, your humble narrator demonstrated the Continuous Integration goodness provided by Team Foundation Build.

As advertised, here is a .zip file containing some of my materials from the presentation:

• The Powerpoint (2007) Presentation
• MSBuild Code Snippets for adding automated deployment to a Team Build

Also, just because I like you, here is a trail of uniform resource locators that will perhaps begin to quench your thirst for Team System/Team Foundation Build knowledge.

• The Team System 2008 Trial Virtual PC Image (Microsoft)
• Team Foundation Build Overview (MSDN)
• VSTS for Team Foundation Server Tutorials (visualstudioteamsystem.com)
• 7 Steps to MSBuild (Brennan’s Blog)
• Team System Videos (Team System Rocks)
• Team Build Target Map (Accentient Blog)

Thanks to Tahmoures and Jason, and the rest of the Aptera Developers.  You guys rock, and I had a blast.

Post-Script

I figured out why the ClickOnce app didn’t deploy!  Those of you who were still awake at the end of my part of the presentation know what I’m talking about.

It seems MSBuild targets are not at all like .NET events, in that you cannot have multiple separate “handlers” for the same target.  I had one Target node addressing the AfterDropBuild target for deploying the website, followed by another Target node also addressing the AfterDropBuild target for the ClickOnce publish.

When I merged them into one Target node, the heavens opened up and there was automated ClickOnce publishing:

  <PropertyGroup>
    <TargetPath>\\TFSRTM08\ApteraDemo\FanSite\</TargetPath>
    <WebSiteFolder>ApteraFanSite</WebSiteFolder>
    <ProjectPath>Main\Administration\Administration.csproj</ProjectPath>
    <PublishPath>\\TFSRTM08\ApteraDemo\Admin\</PublishPath>
  </PropertyGroup>
  <Target Name="AfterDropBuild">

    <!--Deploy Website-->
    <Exec Command="xcopy /y /e "$(DropLocation)\$(BuildNumber)\Release\_PublishedWebsites\$(WebSiteFolder)" "$(TargetPath)""/>

    <!--Deploy Windows App-->
    <MSBuild Projects="$(SolutionRoot)\$(ProjectPath)"
		  Properties="PublishDir=$(PublishPath)"
		  Targets="Publish" />

  </Target>

Aptera is excited to announce that it will host a Tweetup on June 25, 2009 at its downtown offices on the corner of Main and Harrison. A Tweetup is an event where people with a Twitter account can meet face to face. Since Twitter makes it possible to meet friends online without ever meeting in person, a Tweetup gives friends a chance to put faces with names and communicate outside the boundaries of a 140 character Tweet.

Anyone from Fort Wayne or the surrounding regions is invited to attend. Refreshments will be provided by Aptera. To encourage interaction, we will introduce a theme based on the unique knowledge of each person and what we can learn from each other. The Tweetup will begin at 5:00 p.m.  A short welcome speech and introduction will be given at 5:30 p.m.

Stay updated by following Aptera on Twitter at: www.twitter.com/apterasoftware

RSVP for the event online at: www.apterainc.com/rsvp

Microsoft’s ASP.Net MVC Framework was released in March 2009.  Like most software developers, I always want to get my hands on the latest and greatest.  The MVC architectural pattern has been around forever (Wikipedia says 1979), but Microsoft’s implementation for ASP.Net is new.  So, I’ve been itching to get a project to use ASP.Net MVC with.

Me 10 years ago, would want to dive in and rewrite the last few projects I’d worked on, and insist my next project use ASP.Net MVC.  10 years and several projects later, I’ve learned that you can’t ”Put your Resume Ahead of the Requirements“.  The architecture has to fit the project’s requirements, not the other way around.

So before I put MVC on my resume, what is the right situation to use it? 

Let’s start with a very brief explanation of what ASP.Net MVC is. For more information check out www.asp.net/mvc. 

There are 3 functional areas of an MVC application - Model, View, and Controller.  The Model contains the domain objects, rules, and properties.  The Controller classes perform the mapping between the web request and the corresponding Model operation.  Finally, the View is the HTML representation of how the web response data should be displayed.  

Because the Controller class is performing URL routing, we can have friendly URLs that reflect the intent of the request. The URL to Edit Employee 1 could be… http://localhost/Employees/Edit/1.  This site’s URLs are formatted as {controller}/{action}/{id}, but this is configurable.  Additionally, if the routing format included an employee name or product name, URLs could be optimized for SEO purposes… http://localhost/Companies/Details/1/Aptera-Software. 

Back to the topic - what is the right situation to use MVC?

It sounds simple, but if the advantages out-weigh the disadvantages, then it is the right situation.  For the sake of this discussion I am limiting the choices to using either ASP.Net MVC or ASP.Net Web Forms (traditional ASP.Net). 

The advantages of ASP.Net MVC include Unit Testing, Separation of Concerns, and complete control and extensibility of the framework. 

• Unit Testing - A greatly enhanced ability to isolate individual units to test.  Unit tests can create mock implementations of required references, such as HTTPContext. This allows for predicable and repeatable testing inputs.
• Separation of Concerns - While this can be implemented in a properly designed Web Forms application, it is the natural design of an MVC application. 
• Extensibility - Where an ASP.Net Web Forms application provides a lot of functionality for you, it’s not always what you want.  The MVC framework allows you customize every step of the HTTP process - extending or replacing components as you see fit.  It’s very powerful, but requires work to develop.

The advantages of ASP.Net Web Forms include rapid development for smaller applications, a large collection of server controls, and existing developer expertise.

• Rapid Development - ASP.Net Web Forms handles almost all of the HTTP implementation details between a page request and response.  Page and control events are provided and extended from the System.Web.Page assembly.
• Server Controls - Visual Studio ships with a large collection of server controls for ASP.Net Web Forms, and there are many other 3rd party control developers providing specialized controls.
• Developer Expertise - The ASP.Net Web Forms framework has been developed against for almost 8 years, and has a large group of experienced developers.  It will take some time for developers to ramp up on MVC, if they are not already familiar with the framework concepts.

I would suggest that if a project is large enough to benefit from a more extensible framework, or if unit testing is critical, then that project would be a good candidate for MVC.  If the project deadline is too aggressive to allow ramping up on the new framework, you may have to fall back on Web Forms.  Until I get that right project, I’m reserving a spot on my resume, but I’m not rushing it.  I think Me 10 years ago would begrudgingly understand. 

Also note that the decision does not have to be limited to either MVC or Web Forms.  In the right project, they can be used side-by-side, taking advantage of the strengths of both.