Adam just recently posted about refactoring NAnt build files to introduce a much clearer understanding of NAnt and associated build files for people who may not be familiar with typical NAnt style naming conventions. I am definitely a culprit of the style of naming that he dislikes (when it comes to my NAnt files!!), and will definitely take his recommendation to heart when introducing NAnt in the future!!

I finally set up a googlecode project to host source code for the various things I have been doing over the last year. The first major significant contribution is of course the code drop that I promised a week ago now!!

The application is the start of what I hope will evolve to be a great learning resource for lots of things related to .Net development. The application does not currently cover any of the “extra” topics that I did not have time to get covered in the course. This is perfect because as request come in from people (including past students) asking how to tackle a certain problem, I will use this application as the demonstration area where I can tackle the problem, and update the code base, and you will be able to update your local copy and carry on.

I am currently in the midst of a large Smart Client application that I am hoping to be able to harvest pieces of code out and do the exact same thing except for the smart client realm. I have much more experience developing in the smart client realm and that is where I feel most comfortable, so I am looking forward to be able to do another code drop (for a different application) in a couple of months.

I am going to write up another post about the Web Application as it is built very differently from traditional .Net based web applications. In following with the theme for my courses, there are currently no 3^rd party frameworks (other than log4net) that have come into play. My goal with this web app is to demonstrate to people how far we can push raw .Net. The goal being that expanding their knowledge of how to creatively leverage .Net, they will be better prepared to jump into frameworks that they may currently feel daunted by. As time goes by, I will swap pieces of the application out with components that people are asking to see meaningful samples on:

• NHibernate
• Castle
• Prototype
• JQuery
• ..*

As the app stands right now I see it as the beginning of what will shape up to be a pretty mean machine!!

I am going to post a screencast that will show people how to get started working with the web application. For people who are eager to get going right now, here are the quick and simple steps without a lot of explanation (that will come in the next post):

• Anonymously checkout the trunk from the google code repository using the following svn command line:
  svn checkout http://jpboodhoo.googlecode.com/svn/trunk/ jpboodhoo-read-only
  
• Navigate to the checkout folder
• Go into the build folder
• Copy local.properties.xml.template and paste it into the same directory, then rename the copied file to local.properties.xml
• Open up the local.properties.xml file with your favourite text editor.
• Modify any of the settings in the file that are different on your machine.
• Open up a command prompt and navigate to the build directory of the code.
• type: build load.data and hit enter.
• type: build test.all.woc
• type: build run
• The last task should fail (I haven’t automated everything yet)
• Create a virtual directory called nothinbutdotnetstore that points at the following location (this location is created after you attempt to run the build run task) : ${checkoutfolder)\build\deploy\web\app
• After successfully creating the virtual directory try the build run task again.
• If the web browser pops up pointed at a web page (for the app) you are in business. Feel free to click through the first set of pages that are implemented (only 3 pages are currently implemented).

As far as what I have planned to implement in the web app (that is currently not implemented):

• Build out a more extensive domain model that encompasses some more advanced scenarios of the application (especially around order processing).
• Unit Of Work for the service layer
• Implement a lightweight OR/M layer
• Integrate some UI frameworks like prototype
• Eliminate Master Pages completely and switch to a much more elegant template view pattern.
• Introduce a more robust container (as the current one is a simple dictionary wired up in a simple procedural fashion).
• Introduce the concepts of lifecycles for the items in the container. Right now, everything wired into the container is essentially a singleton.
• Introduce CSS based layout for the web pages (working with a designer on this one).
• Bring security concerns into play
• Demonstrate how to effectively manage sessions
• ……lots,lots,lots more!!!

Obviously I will be leaning on people checking out the code and playing around with it and submitting requests for things they would like to see.

There are a couple of things that you will immediately notice about the application:

• Clean front controller implementation with ASPX pages as the template views. There are no code behind pages in this web application. All web requests are handled by command objects that interact with the service layer, push the details into a “ViewBag” and then choose which view to render.
• Logical layers in the project are separated using simple folders and namespaces (not full blown projects)
• Build automation is its own project in the solution (props to Jay Flowers for this inspiration)
• The current container implements (CustomDependencyContainer) is very simple and is handled by a big procedural application startup task.
• Compile time support for the database layer. A couple of classes ago I introduced the concept of a generic TableColumn<T> type. In England after introducing this concept Scott Cowan leveraged his knowledge of MyGeneration to automatically generate strongly typed table definitions that we could leverage to do mapping (trust me when I say, this is nothing like datasets). Until moving into OR/M concepts deeper this gives a good place to start as the generation of the TableDefinitions is linked to whenever the SQL files change, so you will get compile errors if column types are now mismatched etc…

There are lots of other things I could talk about, but this code really is the start of what I see being a long running conversation between myself and other people wanting to learn. In all honesty for all of the emails I have not paid attention to this year, hosting code through google will allow me to answer peoples questions in a much more meaningful way as I can point them at this site to see the implementation of the code they had questions about.

I am going to be placing all of the code for presentations that I have done for the last year as well as continue to update it with the source code that comes out of new courses that will be coming out in the new year, and the DNRTv episodes.

Once again, the application is currently in its infancy, but as people start sending in the requests I now will have a venue and example to add upon to answer questions in a much more timely fashion!!!

 

Develop With Passion!!!

 

 

It's been a while since I used studio to create a deployment project. I am using NAnt to package my files for distribution, I then create a Setup project in my solution that basically points at the NAnt output and creates an MSI from it.

I created an installer for a windows service, and added a custom commit action to make sure the ServiceInstaller ran during the commit phase of the installation.

Upon running the installer I was prompted with the following error message while nearing completion of the installation:

After a bit of digging around it seems that I have to also add a custom install action that is identical to the commit action. Once that is done, the error disappears and the service installs correctly.

Make sure you also add the custom action to the Uninstall step, otherwise the service will not be removed from the computer during uninstall.

Hope this helps someone else.

I received the following question a couple of days ago:

What do you suggest when having a (in house) library being used by several independent projects?

In practice the simplest solution to this problem, and also (by coincidence) the one that causes the least headaches is to treat those "libraries" as just that, "libraries". It can be too tempting to come up with fancy solutions that brings in the source code of these "shared" projects into your solutions so that you can edit the library code on the fly when needed. This ,however, can open up a maintenance nightmare, as a change that is required for one dependent project may inadvertently cause a bug or disable functionality in another dependent project.

To save myself the pain of dealing with these shared projects, I treat them like I would any third party library. I take the dll's and place them in a subfolder of the lib folder of my project. The lib folder is where I place any 3rd party assemblies that I happen to be using on a project. Here is an example for a project I recently completed:

 

Inside each of these respective subfolders is all of the dll's required for that third party dependency. All I would have to do is create a new subfolder named using the in house library I want to consume, and I would drop the latest current version of that assembly into the folder under the lib directory.

As I am developing my dependent app against this library, I am shielded from any changes that may be going on with the "shared" project, as I am just making references to the dll that lives in my lib folder. If a feature gets added into the shared library that I would like to consume in my dependent project, I could follow these steps:

• Rename the existing library in my lib folder to something like : $LIBNAME$.bak
• Drop in the new assembly into the lib folder
• Run any unit/integration tests to ensure that the new assembly does not break any existing functionality in your dependent app. If it does, and you require the new feature, you will will obviously have to fix the dependent app. 
• Delete the old version of the assembly as it no longer needs to be in the lib folder

As you can see, extremely simple. This has worked for me on small, and very large projects. Hopefully you can take this idea and use it to fit your shared library dependency issues.