myVSTS December 2009 Technical Talk (Presentation Slides)

This month we have invited Prabhu, an IT Analyst working with Cargill to share his experiences on migrating from Visual SourceSafe to Team Foundation source control. Cargill is an international provider of food, agricultural and risk management products and services. Founded in 1865 as a single grain elevator in the United States, Cargill employs more than 153,000 people in about 66 countries. Cargill has been conducting business in Malaysia since 1978 and has a significant presence in this country. Headquartered in Menara TM, Kuala Lumpur, Cargill currently employs more than 500 people at six locations.

 

Who Should Attend?
Software Developers, Software Architects, Project Managers, Quality Assurance Engineers, Quality Assurance Managers

About the Speaker:
Prabhu is borned in India. He is currently working with Cargill Malaysia as an IT Analyst for the past 1 year. He has more than 4 years of experience in ASP.NET. He is a cool simple gentleman and always like to hang out with his friends. His hobbies are watching movies, photography, and playing all kinds of sports especially cricket.

 

About the Talk:
Prabhu will share his experiences on migrating from Visual SourceSafe to Team Foundation source control at Cargill. Migration is the process of moving source code files into Team Foundation. Team Foundation includes converters to migrate the source files into Team Foundation. He’ll cover the various steps to follow before migration (pre-migration), during migration, and after migration (post-migration) to ensure a successful migration from Visual SourceSafe to Team Foundation source control.

 

Just managed to snap a few photos. 🙂 You may visit the album at: http://cid-d1df34a904545dc5.skydrive.live.com/browse.aspx/myVSTS%20December%202009%20Technical%20Talk

 

For those who missed this month’s talk, please feel free to download the presentation slides. 🙂 I have also added a video that shows the steps to migrate the code and artifacts from Visual SourceSafe to Team Foundation Server.

 

Presentation Slides:

http://cid-d1df34a904545dc5.skydrive.live.com/self.aspx/Public/myVSTS/Visual%20SourceSafe%20to%20Team%20Foundation%20Source%20Control%20Migration.pdf

http://cid-d1df34a904545dc5.skydrive.live.com/self.aspx/Public/myVSTS/Visual%20Studio%20Team%20System%202010.pdf

 

How Do I: Migrate Code and Artifacts from Visual SourceSafe to Team Foundation Server?

http://www.facebook.com/event.php?eid=221669419459&index=1 (if you have a Facebook account)

http://msdn.microsoft.com/en-us/teamsystem/bb879967.aspx (if you do not have a Facebook account)

 

myVSTS Community Group Facebook URL: http://www.facebook.com/group.php?gid=32952364537

Advertisements

Automatically Implemented Properties (C#)

C# 3.0 was released as a part of the Microsoft .NET 3.5 Framework. In this blog post, I’ll cover the automatically implemented properties feature of C# 3.0. Automatically implemented properties offer a concise syntax for implementing property accessors that get and set a private field. They create a field backed property without requiring you to actually create a field. The compiler automatically generates it for you at compile time. They can be used only for simple get and set of properties because there is no body and no field. No property body means no breakpoints or validation logic can be used. No field means no default value. Typing "prop [tab][tab]" is the Visual Studio code snippet for producing an automatically implemented property. This can make your code much more concise. A classic example of a field back property is shown below:

 

private int myProperty = 0;

 

public int MyProperty
{
   get { return this.myProperty; }
   set { this.myProperty = value; }
}

 

The above code snippet can be refactored to use automatically implemented properties as shown below:

 

public int MyProperty
{
   get; set;
}

 

The above code snippet can be refactored to include a private set and use a constructor to control the value as shown below:

 

class Customer
{
   public Customer(string customerKey)
   {
      CustomerKey = customerKey;
   }

 

   public string CustomerKey { get; private set; }

   public string ContactName { get; set; }
   public string City { get; set; }
}

 

Although this does protect the field from the outside, it could still be altered internally to the class. In reality, an automatically implemented property probably isn’t appropriate for the CustomerKey property and the above code snippet can be further refactored to:

 

class Customer
{
   public Customer(string customerKey)
   {
      this.CustomerKey = customerKey;
   }

   private readonly string customerKey;

 

   public string CustomerKey
   {
      get return this.customerKey;
   }

 

   public string ContactName { get; set; }
   public string City { get; set; }
}

 

The above code snippet illustrates the point that the automatically implemented properties should be applied liberally, but with caution.