Shane Bauer Blog
.NET, ASP.NET and Software Development

Subversion, TeamCity, and Rake = Wow

October 28, 2008 15:31 by sbauer

Whenever I start a new project there are certain things that I always need to do. I need to setup the source code repository, create a basic project structure, create a build script to build the project, and setup the project on a build server.

A few months ago I realized just how much I hated doing all of this. Setting up the repository was the easiest part. I've been using Subversion for years. Instead of hosting my own subversion server, I use a third party. I'll let them manage the server, subversion upgrades and the backups. Because of this, setting up the repository was basically logging into a control panel, filling out a form, and that's basically it. However, after this was completed, the tasks became much more redundent. 

For the longest time I used NAnt for my build engine. It is a good tool, no doubt. The problem is I hate XML. I hate it. It's not the language itself really. It's how people use XML. NAnt uses XML as the way to write the build script. I hated creating the scripts and I hated modifying them.

Of course, my XML troubles didn't end there. I used CruiseControl.net as my CI (build) server. The application itself is OK. It's not great and has aged quite a bit. By far my biggest problem with CC.NET is the process of adding a new project. In order to add a new project to CC.NET, you must modify an XML file. If you have many projects configured, that file may be quite large.

I don't know about you, but after setting up my build script and setting up the project in CC.NET, I'm pretty tired of looking at XML.

Taking a look at TeamCity

After reading a ton of blogs and twitter messages from people talking about TeamCity, I decided to give it a shot. I wasn't really sure what to expect. I thought it would be good as I'm a huge ReSharper fan (the same company that makes ReSharper also makes TeamCity), but didn't really know if it would fit my needs.

Fortunately, JetBrains (makers of TeamCity) markets a version of TeamCity targeted for smaller teams that doesn't cost a thing. I grabbed it, installed it on a VM, and played around. To make a long story short, I'm still using it. TeamCity is a really nice CI server. It's very extensible and configuration is a breeze. You can add projects and build configurations straight from the browse. No need to modify XML files. TeamCity supports a number of different version control systems and build environments out-of-the-box. NAnt, MSBuild, Ant, and command-line are just a few. Because of this I was able to migrate my project from CC.NET to TeamCity in no time. 

Replacing NAnt with Rake

After deciding to go with TeamCity, I felt pretty good. I had solved one problem. I cannot tell you how much time I've saved because of it. After a while, though, I started to look for replacement options for NAnt. Like I said before, I like NAnt, but I wanted something better than XML. After doing some research, I decided to look into Rake, a build tool programmed in Ruby. I noticed a few .NET developers using Rake successfully. One evening I loaded my NAnt build script and replicated the entire script using Rake. I've done some work in Ruby so it didn't take that long to convert everything over. Obviously, you don't have the pre-made nant tasks, but creating a reusable framework that calls the executables for various tools (msbuild, nant) wasn't too bad. After I got it working locally, I modified my existing build configuration in TeamCity to call the new rake script. Initially, I used the rake runner in TeamCity. After a while, I wasn't getting the results that I wanted so I switched to the simple command-line runner. After tweaking a few minor things, I was done. 

Looking Back

I'm really satisifed how things turned out. TeamCity is a joy to work with. Managing Rake build scripts instead of XML files just feels right. If you're looking for a replacement or you're just getting into this territory, you should really take a look at TeamCity and Rake.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:
Categories: .NET | .Software Development
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Tip: Register Windsor Dependencies via Code, instead of XML

April 25, 2008 15:32 by sbauer

One thing I never really liked is component registration via XML. If you were to remove a class, and forgot to remove the class from your configuration, you would find out at runtime. I'd much rather find out at build time and get the benefits from the refactoring tools.

You can do this by registering your components in code. Typically, you would register your components during application startup.

container.AddComponent<IPlayerService, PlayerService>();
container.AddComponent<IBallparkService, BallparkService>();

You have several different options when adding components. In my example, I'm just specifying a service (the interface) and the concrete class (BallParkService) that will be used. When my application needs a IBallParkService, Windsor will pass along the BallparkService. Since I didn't specify a lifestyle, the default transient lifestyle will be used. The transient lifestyle will create a new instance for every call. There are other options, though, that you can use depending on your needs. 

 


Currently rated 1.0 by 1 people

  • Currently 1/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

CMAP Code Camp Spring 2008

April 13, 2008 09:21 by sbauer

I went to the Spring 2008 CMAP Code Camp yesterday with a friend and former co-worker yesterday. A lot of good sessions all around.

 A Gentle Introduction to Mocking -  Scott Allen discussed the basics of mocking with Rhino Mocks. Later, he switched it up for a test and used Moq. Pretty interesting stuff. Nothing completely mind blowing, but it was a little different. He also used xUnit.net as the unit testing framework. That was the first time that I had a good look at xUnit.net and Moq. Thanks Scott.

C# 3.0 New Features - Kevin Jones discussed all of the new features of C# 3.0. Lambda expressions, anonymous types, LINQ and everything else. Thanks Kevin.

 Decouple Your Applications with Dependency Injection and IoC Containers - Matthew Podwysocki discussed quite a few different things related to dependency injection and IoC Containers. He also gave a few demos using Windsor as well as Unity. Thanks Matthew

 Create AJAX Applications Using JQuery and ASP.NET MVC - Emad Ibrahim had a session on ASP.NET MVC and jQuery. He gave a good overview of a few ASP.NET MVC features and dove into jQuery. Given the short amount of time, he was able to show a few of jQuery's powerful features and even demo a site that he's created using both, Yonkly. Thanks Emad.

 Free sessions, free food, free prizes. You really can't beat it. Thanks to the CMAP group and the volunteers.

My goal is to blog about a these few areas shortly.

 


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

ASP.NET: Web Controls have an ID, a ClientID and a UniqueID. What's the deal?

November 8, 2006 11:05 by sbauer

While working on your ASP.NET page, you may have noticed that all of your web controls contain three different ID properties. That's great. But why? Uniqueness.

Lets say, for example, you have a Repeater control. In this Repeater control, you have an itemtemplate that contains a textbox and a label. Your label is called "ProductName" and your textbox is called "ProductQuantity". If your repeater contained more than one item, you would run into issues with html elements being named the same. That's a huge problem.

UniqueID fixes this issue. When the control gets created, a uniqueId is generated based on the control's heirarchy. For example, a textbox within a CreateUserWizard would have a UniqueID similar to "CreateUserWizard1$CreateUserStepContainer$Email". The UniqueID, as you can see, is a large string seperating the control's parents by a dollar sign. Pretty simple.

However, that's not technically valid in the HTML world. ClientID fixes this problem. ClientID replaces the invalid separator with a valid separator, like an underscore. Therefore, the textbox within the CreateUserWizard would have a ClientID similar to "CreateUserWizard1_CreateUserStepContainer_Email". As a result, when your textbox is rendered as a standard input element, the ID field would contain the value in the ClientID property.

If you want to access your control via javascript, don't use the ID property, and don't use the UniqueID property. Use the ClientID Property.

ConfirmButton.Attributes.Add("OnClick","javascript: alert('The username textbox as a value of " + Username.ClientID + "')";


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:
Categories: .NET
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed

Stored Procedures and .NET Part I: Executing Simple Stored Procedures

November 13, 2004 00:16 by sbauer

For what it's worth, I enjoy using Stored Procedures. I know there have been quite a few debates over the last year regarding myths and facts involving them, but I would rather not get into that right now. Instead, I'm going to show a few stored procedure examples.

Stored Procedures allow you to store all database-related queries and other transactions inside of the database. Some argue about the actual benefits, but either way, they have a place in the database world.

Before I continue, you must know that stored procedures accept three types of parameters: input, output and return. Input parameters take data from the outside world into the stored procedure. Try to think of a standard function in any programming language and the parameters they accept. Those parameters are similiar to stored procedure input parameters.

In my first example, I'm going to create a simple stored procedure that INSERTs a record in a table.

AddUser.sql
-----------------------------------------------------------------

Create Procedure dbo.AddUser
(

@username varchar(50),
@first_name
varchar(50),
@last_name
varchar(50)

)

AS

insert into tblUsers(username,first_name,last_name) values(@username,@first_name,@last_name)

In this example, my stored procedure, AddUser, is owned by the dbo and takes three input parameters: @username,@first_name, and @last_name. In addition, it inserts these values into the tblUsers table.

Since the SQL statement is inside of the procedure, you won't need to execute the same INSERT command inside of your .NET. Instead, you will call the stored procedure and specify the parameter values. But first, lets create our connection and command objects.

SqlConnection conn = new SqlConnection("connection_string_here;");
SqlCommand cmd = new SqlCommand("AddUser",conn);
cmd.CommandType = CommandType.StoredProcedure;

The code above creates our connection object, conn, and sets the connection string. Depending on your database information, you will need to change that. After that, our command object, cmd, is created. For the purpose of this example, the SqlCommand constructor takes two parameters: the text for the sql command and a connection instance. Because our stored procedure is called “AddUser”, we specify that in our first parameter and type conn in our second parameter. You'll also notice that I have specified a commandtype. This tells ADO.NET that we are trying to execute a stored procedure, not a standard ad-hoc query. If you forgot that portion, you would get an error because AddUser is not a valid SQL command.

Next, we need to specify our parameters. If you didn't specify any parameters in your stored procedure, you wouldn't need to write the following lines of code. However, since I did, I need to specify the parameters or else my application would complain.

SqlParameter param = new SqlParameter("@username",SqlDbType.VarChar);
param.Value = "sbauer";
SqlParameter param2 = new SqlParameter("@first_name",SqlDbType.VarChar);
param2.Value = "Shane";
SqlParameter param3 = new SqlParameter("@last_name",SqlDbType.VarChar);
param3.Value = "Bauer";
cmd.Parameters.Add(param);
cmd.Parameters.Add(param2);
cmd.Parameters.Add(param3);

In the piece of code above, I have created three SqlParameter objects (one for each parameter). In the constructor for each one, I've specified the parameter name, and the database data type. As you can tell, our parameter name and data type match what it is in stored procedure. After we initiate each object, I then had to specify the value. I simply used hard-coded strings, such as “Shane” and “Bauer”, but you can use variables as well.

Once you have created each parameter, you must put each parameter inside of the command object's parameters collection. To do this, you simply do: cmd.Parameters.Add(YOUR_PARAM_OBJ_HERE).

Once you have added your parameters to the collection, all you need to do is open the connection, execute the command and close the connection. Because our command doesn't return a resultset, you can use the ExecuteNonQuery() method of the SqlCommand object.

conn.Open();
cmd.ExecuteNonQuery();
conn.Close();

Assuming you have setup the database correctly, your command should execute.

If you want to know more technical details about stored procedures, check out a few sites on the web. My goal was to give a brief overview of stored procedures, while showing you how to use them in .NET. Tomorrow, I will explain Output and Return value parameters.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags:
Categories: .NET
Actions: E-mail | Permalink | Comments (0) | Comment RSSRSS comment feed