CHAPTER 1 ■ GETTING STARTED
14
Page Designer, Markup, and Code
The center of the workspace is the designer and code editor. Just like in Visual Studio, you can have a split view, all
design, or all markup. You can also load code files into the center pane. While you get features like Intellisense, the
development experience doesn’t contain all of the great features of Visual Studio like navigation and refactoring.
Plus, you lose any productivity plug-ins like Telerik’s JustCode that you might have installed in Visual Studio.
Properties, Resources, and Data Tabs
The right rail of the workspace contains the Properties, Resources, and Data tabs, which can be described as follows:
The Properties tab is where I spend a significant portion of my time in Blend. In addition to •
the simple items like Name and Layout and properties like Width and Height, there are a host
of properties that are difficult to set by hand in markup. Brushes, Transforms, and Interactions
can all be set using the Properties panel.
The Resources tab contains all of the application and page-level resources as well the option •
to edit and add more resources.
The Data tab allows you to set the data context for your page, create sample data, and create •
different data sources. This is helpful to see what the page will look like with data at design
time instead of always having to run the app.
Blend for Visual Studio is an extremely powerful tool and it would take an entire book to discuss all of the
features. My development workflow involves keeping both Visual Studio and Blend open at the same time, and I
switch back and forth depending on what I am trying to accomplish. Explore Blend, and see what works best for you.
Git
Software version control has been around for a long time. If you have been in the Microsoft space for a significant
length of time, you might remember Visual Source Safe. In the .NET world, the MS developer was left with Team
Foundation Server (TFS) as the only integrated source-code-management (SCM) system.
TFS is a powerful application lifecycle management (ALM) tool (including project management, bug tracking,
SCM, and other components). That is a lot of tooling when you are only looking for SCM. The SCM portion of TFS is
Team Foundation Version Control (TFVC) and is a centralized SCM system. This means that a single repository is the
source of record, and all developers check their code in and out of this single repository. Later versions of TFVC have
included the capability to shelve work and create branches, providing some isolation for work in progress.
Git, developed by Linus Torvalds in 2005 for the Linux kernel, is a distributed version control system (DVCS). This
means that every developer using Git has a full-fledged repository on his local machine with complete history and
tracking capabilities. Many Git users (especially in a team environment) have a central repository in addition to their
local repository. This frees the developer to spike different ideas, work on features independent of the rest of the team,
and check in rapidly as often as they like without worrying about network latency or affecting other team members.
Which SCM system you choose to use is completely up to you. They both have their merits (and there are many
other SCM systems available to you as well that are very effective in what they do). It’s more how you work and whom
you work with that usually determines which system to use. So why do I bring up Git specifically in this book? Because
if you are a single developer creating a Windows 8 app, Git is custom tailored to you, and with Visual Studio 2013
(and updated to Visual Studio 2012), Git support is now included.
There are entire books written about effectively using Git, so this is just a quick look into the Visual Studio
integration, and not a treatise on DVCS.
Using Git in Visual Studio
One of the advantages of using Git is its simplicity. A Git repository can be created anywhere—on a local disk, network
share, or web site (like GitHub).