Tag Archive for: best practice

Deploying files with CruiseControl.net using xcopy

Each CruiseControl.net job that needs to deploy files to a web server, does this through a batch file.  Inside that batch file is an xcopy command.

Here is an example

xcopy /exclude:..Scriptsexcludes.txt /E /F /Y /M .DerbyDerby.Website*.* \SBD-WEB-1inetpubDev1.derby.reurgency.netDerby

NOTE: the current working directory is always the folder called “Working” in our standard folder structure.

You will notice that the xcopy command uses a variety of switches that require some explanation and some WARNINGS.  Look at documentation here: http://support.microsoft.com/kb/289483

Here are my notes regarding these switches:

/exclude allows to exclude certain files. Those file names are listed in the excluded.txt file. At a minimum this should contain one entry for web.config.

/E copies any subfolder, even if empty.  This ensures that the proper structure exists on the web server.

/F displayes the full source and destination file names will copying.  This is helpful when looking at CC.net logs.

/Y overwrites existing files without prompting.  Important not to prompt since this runs automatically.

/M copies files with the archive attribute set.  This switch turns off the archive attribute.

That last switch /M works great as long as you only have one deployment script for this website using that switch.  i.e. if you have both a dev1 cc.net project and test1 cc.net project you will have a problem with that switch.

Here’s the way it works with dev1:

  1. CC.net gets latest files from SVN. Any new or modified files get their archive bit set.  This is not a CC.net thing, this is a basic feature of every OS file system.
  2. CC.net builds DLLs.  All DLLs build have their archive bit set.  Again, just basic file system behavior.
  3. CC.net runs the deploy batch file that contains the xcopy.  The xcopy  uses the /M switch which tells it to only copy the changed files (archive bit set).  It also resets the archive bit so it is not seen as changed the next time it runs.

This process makes deployments much faster.  However, it only works if there is one entity clearing that archive bit.  As soon as you have another environment (e.g. test1) you cannot use that trick for those other environments.  The issue is that two jobs are stomping on each other’s record of what has changed.  After a few runs, they will BOTH have out of sync files.

Therefore, here is best practice:

  • Dev1 will always use the /M switch because those deploys happen more frequently and we benefit the most from only copying changed files.
  • All other environments (Test1, Demo1, etc) will NOT use the /M switch because those jobs are run less frequently and it is OK if all files get copied each time.


C# Model Coding Practices

What is a model?  A model is a programmatic representation of a concept or physical object that exists in real life.  We represent models in code as Entities in C# and as Tables in the Database.  Since these entities and tables represent the same underlying model, they need to remain synchronized.  In the past, generally the database was created first and then the entities were generated from it.  Recently, this paradigm has changed…

Now, we are using a code-first model creation paradigm in which the programmers write the C# Entities and from those entities the database is generated.  When working in this manner, there are best practices that will make the process more simple.

First, when creating the entities, adhere to the Database Design Standards set by Ty.  Even though this document was written for designing databases, it still applies.  Just substitute “Entity” for “Table” and “Field” for “Column” and you should have no problems.  In addition to this, make sure to make all fields virtual.

public virtual int UserRoleId { get; set; }

Next, for any foreign key field, add another field named and typed the same as the foreign key entity.  For example:

public virtual int UserRoleId { get; set; }
public virtual UserRole UserRole { get; set; }

This gets us most of the way to where we want to be, but sometimes we want certain behavior in table or column creation, in how Entity Framework treats the entity, or in data serialization.  Below are a list of common attributes and what they do:

Class level attributes:

  • DataContract – Tells the data serializer that we are using an opt-in policy.  This means that only fields which are decorated with the DataMember attribute will be serialized.  This attribute is highly recommended as it gives you complete control over which fields are transmitted.
  • Table – Specifies to the code-first model generator the table name that you wish to map this entity to.  This is useful if you want the table to be named something different than the entity and is not required in most cases.

Field level attributes:

  • DataMember – Works with the DataContract attribute.  Used to specify that the field it decorates is meant to be serialized.
  • Key – Identifies this field as the primary key for the database table it represents
  • DatabaseGenerated – Indicates to the code first model generator and Entity Framework that this field will be updated by the database and not the user.  This can be applied to fields like primary keys and database generated dates (last update date) but use discretion as to when you apply this attribute.
  • Required – Tells the Entity Framework validator that this field is required and allows you to specify an error message upon failed validation
  • StringLength – Tells the entity validator that this field has a max and min range for string length and allows you to specify these ranges and an error message.
  • Display – An intended display name for the field
  • ForeignKey – Indicates that the field is a foreign key

Below is an example of a class which uses most of these attributes:

    public class User
        /// The identifier for the user.  Also the primary key.
        public virtual Guid UserId { get; set; }

        /// Foreign key to the UserRole table/object.
        public virtual int UserRoleId { get; set; }

        /// UserRole object associated with this User.
        [ForeignKey( "UserRoleId" )]
        public virtual UserRole UserRole { get; set; }

        /// The login user ID for the user.
        [Required( ErrorMessage = "Login is required." )]
        [StringLength(100, ErrorMessage = "Login cannot be longer than 100 characters.")]
        public virtual string Login { get; set; }

        /// The hashed password for the user.
        [Required( ErrorMessage = "Password is required." )]
        [StringLength(40, ErrorMessage = "Password cannot be longer than 40 characters.")]
        public virtual string Password { get; set; }

        /// The driver's first name.
        [StringLength( 100, ErrorMessage = "First Name cannot be longer than 100 characters." )]
        [Display(Name = "First Name")]
        public virtual string FirstName { get; set; }

        /// The driver's last name
        [Required( ErrorMessage = "Last Name is required." )]
        [StringLength( 100, ErrorMessage = "Last Name cannot be longer than 100 characters." )]
        [Display(Name = "Last Name")]
        public virtual string LastName { get; set; }

        public virtual Guid BaseUserId { get; set; }


The next step is to create a database context class.  This is how Entity Framework communicates with the database.  You need to add a field which corresponds to each table you want to create in the database from code. Each record in the database context is a line of communication between Entity Framework and the database for the specified table/entity.  After creating your database context, the first thing you should do is remove the convention of cascading deletes.  While this can save time in certain situations, it also allows for the opportunity to delete large amounts of data by accident.  A basic database context class looks like this:

public class DatabaseContext : DbContext
        public  DatabaseContext()
            : base("name=DefaultConnection")

        // tables
        public DbSet Users { get; set; }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)



This can optionally be generated by MVC scaffolding.

The last topic I have to discuss is, “How do I work with database views using Entity Framework and code-first?”  Currently, code first cannot create the view for you.  You need to create the view in the database itself, then create an entity that represents it.  You could probably add the creation script for the view to the migration created by code first, but that would be a topic for a different presentation.  To connect a view to an entity, the procedure is pretty much the same as with a table with the following exceptions:

  • Create the view in the database.  Specify the view’s base table as the “primary key”.  For example, the primary key for a UsersView should be UserId.  While views technically do not have a primary key, this makes Entity Framework happy and generated code works better.
  • Add the “Table” attribute to the entity’s class definition and specify the view name.  Otherwise the code-first model generator will automatically attempt to pluralize your view and it will end up pointing to the wrong object in the database.  Pluralization works well for table creation (Users) but not for views (UsersViews?)
  • Use the add-migration command to create the migration script and then comment out the table creation code.  As stated above, you can optionally add code for view creation here at this time.

Below is an example of the class definition and primary key setup for a view:

    //This makes the database generator link to "HeatDriverYearsView".  Otherwise   
    //it would attempt to pluralize the class name and create a new table 
    public class HeatDriverYearsView
        /// The identifier for the heat.  Also the primary key.
        //Even though views have no primary keys, this property will act like one.
        //There will only be one HeatDriverYearsView record per HeatId
        public virtual int HeatId { get; set; }

It is worth while to note that using views is one of a few ways to handle retrieving data from multiple tables.  Another way is to add commands to existing entities and use LINQ to perform any joins manually.  This has its own set of pros and cons so use your judgement as to which methodology to use.

Best practice for file upload and import

A common feature in applications is the ability for an end user import data from a file.  Generally the best user experience is to allow the user to select a file off their hard drive and upload it to the server for parsing and import into the database.

However, there can sometimes be technical complexity associated with file uploads and that complexity often distracts from the business logic.  We should first work through the business logic of the import before tackling the technical complexities of uploading, storing, parsing, and cleaning up files.

FIRST create a real dumb import screen that just has a text box in a browser.  We can then manually copy and paste into that text box and submit to server for parsing and import.  There are many benefits to doing this first.

  1. Quick to build
  2. Simple to support
  3. Avoid file loading complexity and focus on business process first
  4. Easy to test
  5. Unit test friendly
  6. Great fallback should the more complex solution of file loading ever fail

I am NOT saying don’t build a better user experience.  I am saying build a simple, easily testable feature FIRST that you always keep in your back pocket for a rainy day.