The opinions expressed in these materials are my own and are not necessarily those of Microsoft.
Copyright © Microsoft Corporation. All rights reserved. Unless otherwise indicated, all source code provided is licensed under the Microsoft Public License (Ms-PL).
The first update for VS2013 came out yesterday and is heavy on bug fixes but not much in the way of new functionality. You can download the latest update from here:
Here is a list with the new additions underlined:
Note Unless otherwise indicated, linked items will take you to Microsoft Connect webpages.
Team Foundation Server
Directed Graph Markup Language
The Graphics Diagnostics engine couldn't create a debug device, most likely because the matching Windows SDK for this version of Windows is not installed. Please install the matching SDK and try again.
Visual Studio Test
There was an error while importing the result file. Details: The system cannot find the file specified. After correcting the problem open the results from Load Test Manager.
Release Management for Visual Studio 2013
My very good friend, Randy Pagels, recently posted some TFS usage data. You can find the PDF here:
While you are there make sure to look at all the other great stuff Randy has on his blog:
Here is a quick look at the data for folks:
Team Project Collections
Active Unique Users
Source Code Files
Builds Per Month
As you can see we like to “eat our own dogfood” at Microsoft and we use TFS for our development. What you may NOT know is that TFS is used for way, waaay more than software development at Microsoft and at some of my customers. The traditional fallacy is that TFS is used for only .NET development or for only software development—nothing could be further from the truth. You can use TFS to do anything where you want to have traceability and reporting capabilities. Some of the more common uses I see beyond .NET or Java application development is the use of TFS for mainframe development and hardware development. We use TFS, for example, to create the Xbox 360 (and Xbox One) hardware elements such as controllers, Kinect, and so on. So the next time you are thinking of using TFS remember the technology transcends any particular technology and can be used for much more than just .NET development.
I recently had a discussion with a customer about our GIT support. I thought I would share this great documentation for folks who are wondering what our current level of support is and a to compare GIT to the Team Foundation Version Control (TFVC). We want to provide folks the ability to choose the version control systems that suits them best so we offer both centralized (TFVC) and decentralized (GIT) version control alternatives natively in TFS. You can find the documentation below here:
When you create a new team project you choose the version control system your team will use in that project: Team Foundation Version Control (TFVC) or Git. This is a permanent choice for each team project you create, but you can use both TFVC and Git team projects in the same team project collection.
Team Foundation Version Control (TFVC) is a centralized version control system. Typically, Team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Branches are path-based and created on the server.
TFVC enables two models for your team to make changes:
Check out/check in in server workspaces: Before making changes, team members publicly check out a files. Most operations require developers to be connected to the server. (In the past teams blocked more than one person from checking out, but this is now less common.) This system facilitates locking work flows. Other systems that work this way include Visual Source Safe, Perforce, and CVS.
Edit and commit from local workspaces: Each team member takes a copy of the latest version of the codebase with them and works offline as needed. Developers check in their changes and resolve conflicts as necessary. Another system that works this way is Subversion.
Learn more about Team Foundation Version Control (TFVC).
Git is a decentralized version control system. Each developer has a copy of the entire source repository on their dev machine. Developers can commit each set of changes on their dv machine and perform version control operations such as history and compare without a network connection. Branches are lightweight. When you need to switch contexts, you can quickly create a private local branch. You can quickly switch from one branch to another to pivot among different variations of your codebase. Later, you can merge, publish, or dispose of the branch. Another system that works this way is Mercurial.
Git in Visual Studio and TFS is standard Git. You can use Visual Studio with third-party Git services, and you can also use third-party Git clients with TFS.
Learn more about Git
Here’s a comparison chart to help you make a choice between TFVC and Git.
Team members can receive email alerts when check-ins occur.
Team members can receive email alerts when commits are pushed to the server.
Because your team checks in all their work into a centralized system, you can identify which user checked in a changeset and use compare to see what they changed. Looking at a file, you can annotate it to identify who changed a block of code, and when they did it.
You can identify which user pushed a commit to TFS. (Anyone can claim any identity as the author or committer.) You can identify when changes were made what was changed using history, compare, and annotate.
Path-based branches are used mostly as long-standing constructs to isolate risk of change among feature teams and releases. Team members typically set up an additional workspace for each branch they work on.
Changes in each branch are independent from each other, so you don’t have to check them in before switching from one branch to another. Merging between sibling branches requires a baseless merging.
You can get visualizations of your branch structures and where your changesets have been merged.
See Use branches to isolate risk in Team Foundation Version Control.
Branching is lightweight and path independent. Many developers create a branch for each new feature they are coding, sometimes on a daily basis. You can quickly switch from one branch to another to pivot among different variations of your codebase. You can create branches that exist only on your dev machine and share them if and when you’re ready.
You must commit, branch, stash, or undo changes before switching branches. Merging is simple and independent of the commit that the branch is based on.
You can compare branches to see which commits exist on which branches.
See Use Git branches to switch contexts, suspend work, and isolate risk.
Builds (automated by TFBuild)
You can use all TFBuild capabilities to build any combination of content you want within the team project collection.
You can use most TFBuild capabilities to build one team project at a time, and one or more repositories at a time. Gated check-in builds aren’t available yet. Symbols can be published, but they are not indexed yet.
Team members can concurrently change files on their dev machines. You upload (check-in) changesets to the server when you create them. You can upload your changes at any time. However, you might be interrupted by conflicts.
You can change the comment of a changeset after you check it in. You can link changesets to work items and associate them with completed builds.
Team members can concurrently change files on their dev machines. You create commits on your dev machine independently of contributing them to the team. When you’re ready you must pull the latest commits before you upload (push) yours to the server. When you pull, you might be interrupted by conflicts.
You cannot change the comment of a commit. You can link commits to work items and associate them with completed builds.
You can modify and combine commits from the command prompt.
Code reviews in TFS
Not available yet, but you can comment on and send email about a commit from the web portal.
You might have to resolve conflicts when you get, check in, merge, or unshelve. You can resolve all types of conflicts in Visual Studio.
You might have to resolve conflicts when you pull or merge. You can resolve content conflicts in Visual Studio. Other types of conflicts can be resolved from the command prompt.
You can check in large binary files. You might also want to use NuGet in combination or as an alternative.
You can check in small binary files. You might want to use NuGet as an alternative.
Files on the client dev machine
You can browse your files using Source Control Explorer in Visual Studio, or using Windows File Explorer or the command prompt.
You can browse your files using Windows File Explorer or the command prompt. You cannot yet browse files in Visual Studio.
Files on the server
Each team project contains all files under a single root path (for example: $/FabrikamTFVC). You can apply permissions at the file level. You can lock files.
You can browse your files on the web portal and using Source Control Explorer in Visual Studio.
Each team project can contain one or more Git repositories and each Git repository can contain one or more branches. The most granular permissions you can apply are to a repository or a branch. Files cannot be locked.
You can browse your files on the web portal.
File history is not replicated on the client dev machine and so can be viewed only when you’re connected to the server.
You can view history in Visual Studio and on the web portal. You can annotate files to see who changed a line, and when they changed it.
File history is replicated on the client dev machine and can be viewed even when not connected to the server.
You can view history in Visual Studio and on the web portal. On the web portal you can annotate files to see who changed a line, and when they changed it.
Manage work on your dev machine
Pending changes and my work pages
Changes, commits, and branches pages.
You can use CI builds, gated check-in builds and check-in policies.
You can use CI builds. Gated check-in builds aren’t available yet.
You can work on small or very large scale projects using local workspaces. Supports massive scale (millions of files per branch and large binary files) projects using server workspaces.
You can quickly begin small projects. You can scale up to very large projects, but you have to plan ahead to modularize your codebase. You can create multiple repositories in a team project.
Suspend your work
You can suspend from my work page or shelve your changes.
You can create a branch from (from Visual Studio or the command prompt) from or stash (from the command prompt)
Tag your files
You can apply labels to a version of one or more files from either Visual Studio or the command prompt. Each file can have label applied to a different version.
You can apply tags from the command prompt to individual commits. View tags in the Visual Studio history window.
Client tools: Visual Studio, Eclipse (with Team Explorer Everywhere)
Server tool: TFS
Client tools: Visual Studio, Eclipse, and other third-party tools
Server tools: TFS and third-party services
Visual Studio: Offers all commonly used features and many advanced features.
TFS web portal: Can browse, comment, annotate, and see history of the codebase.
TF Command prompt: Installed with Visual Studio. Used for advanced, administrative, and other less common tasks.
Visual Studio: Offers many commonly used features. Features for some common tasks are not yet available.
Third-party command prompt: You can install it from Visual Studio. Used for some common and many less common tasks.
Visual Studio compatibility
You can use all supported previous versions of Visual Studio.
You can use Visual Studio 2013 (Git is included) or Visual Studio 2012 Update 3 (you must also install Visual Studio Tools for Git).
You can browse your codebase (including branches), view history, annotate and comment on changesets and shelvesets, and perform other tasks such as ad hoc downloading of selected parts of your codebase as a .zip file.
You can browse your codebase, view history, compare branches, annotate and comment on commits, and perform other tasks such as ad hoc downloading of selected parts of your codebase as a .zip file.
Happy New Year!
It’s time to begin 2014 and get some great stuff going this year!
As many of you know, I very seldom blog about anything personal. There are several reasons for this but the most obvious one is I think you read my blog for tech stuff not my thoughts on the weather. I know there are successful bloggers who do that kind of thing but it just isn’t my style. With that said, I want to warn the pure tech readers that this post will wax introspective and is deeply personal. I would encourage you to read on anyway but it’s your call.
I think we all have moments in life where we are at a crossroads. For me it was deciding to stay in my current role at Microsoft or take a new role with a broader scope across all our product lines. I believe my decision to stay in this role is the right one because of my passion for Visual Studio and TFS. All of these things were not black and white for me; and we all live with uncertainty in today’s world. This year I was lucky to have something happen to show me that there are some absolutes in this world and doing a good thing is always the right thing. I’d like to share that experience with you.
It started on Sunday night, December 29, as the new year was approaching and temperatures were near freezing. My dog, Lily, went out to the yard to take care of business but became unusually interested in one area of the fence. She kept sniffing that one area and suddenly jumped back. I just assumed it was one of the rabbits or other animals that visit from time-to-time and dismissed it. However, the next morning she focused on that same area again and this time I heard a noise on the other side of the fence. My curiosity peaked, I decided to look over the fence. This is what I found:
Freezing and cowering against the fence was an emaciated pit bull. I knew that is what Lily had been investigating the night before and this dog wouldn’t survive if left alone. Gathering up a leash I went around to the other side of my fence to find…nothing. The dog had disappeared and there is a lot of new building around my house so she could have been anywhere. Looking in many of the houses under construction the dog was nowhere to be found. I finally gave up, hoping that the dog would find a place to survive, and was walking back home when something told me to check the house directly behind mine again. She wasn’t in the house but I saw her though one of the windows and, somehow, she had arrived back at the spot I had first searched on the other side of my fence.
Then and there I found a fundamental truth for me: This dog was not going to die. That’s it. A simple irrefutable truth revealed itself to me. The dog will not die. (I’ll pause at this point for the more analytical among you to note that, yes, the dog WILL eventually die as all things do; but she will not die anytime soon if I can help it.) It took me about an hour to convince her to let me put the leash on her as I sat next to her by the fence. It took another three hours to be able to get her into a crate so I could get her to the vet. After a two day visit at the vet, which checked for any type of identification and got her up to speed on all her vaccinations, I decided to call her Maggie.
Unfortunately my current dog doesn’t play well with others so I most likely can’t keep her long term and currently have Maggie at the kennel getting fattened up and socialized with other dogs. I need to find her a home. As you may or may not know, there are two types of dog shelters out there: kill and no-kill. A “kill” shelter will euthanize a dog if they are not adopted over time whereas a “no-kill” shelter will never put a dog down unless there are extenuating circumstances. I went to one of my local no-kill shelters to see if Maggie could be placed for adoption. Sadly they only allow six pit bulls at any one time and they currently have all six slots filled. Undeterred, I am calling no-kill shelters around the area and have placed an ad on a pit rescue site:
My mission is to find her a good home with loving owners who will make sure Maggie has a good life. In other words, my goal is to make sure she doesn’t die. For some reason finding an absolute in the midst of a world of uncertainty helped me achieve some measure of peace. Helping this abandoned dog made me understand that we all need to have these types of events in our lives. I found my truth just before the new year. I hope your found (or will find) yours. :)
This article came about as the result of a recent trip I made to a customer. I was presenting on TFS and made the, oft repeated, statement that Agile is better than Waterfall. Now I have to admit that I have never really had anyone challenge me on this assumption since most of the people I know just accept this as truth. On this particular day there were a couple of project managers in the audience and they were none too pleased about my assertion. For the rest of the hour, we went back and forth on the issue. Following are a few of exchanges to the best of my recollection:
Project managers: “You can’t say that agile is better than waterfall, it simply isn’t true.”
Me: “I have twenty years of evidence backing up my claim and I have personally seen it work this way.”
Project managers: “Well, we have government regulations we deal with and you just don’t understand what we do here.”
Me: “I have [another customer] that has to deal with HIPPA requirements and they use Agile so I don’t think your requirements are that strict, are they?”
Project managers: “We don’t use pure Waterfall we use a modified version.”
Me: “So..you’ve already modified your methodology because it’s inadequate. Why not finish the job?”
Essentially the arguments went on from there but were just variations on these three exchanges. To be fair, I tried to explain that I believe Waterfall has it’s place in many, many areas just not in software development but this argument fell on deaf ears. So it got me to thinking: “Am I right?” I had looked at some evidence years ago and had proven it out myself on countless occasions but was that still the case all these years later? Did Agile methodologies still hold sway over Waterfall? Did the evidence prove it? To that end I have assembled evidence for myself and for anyone else who has to fight the Agile battle. Please feel free to add your own evidence (pro or con) in the comments.
Please note that I deal in empirical data. Period. I can find any number of people (including myself) who have had good/bad experiences with Waterfall and good/bad experiences with Agile. On the main, I’ve found Agile to be better in the situations I have dealt with but I have seen plenty of people swear to Waterfall the same way. To even the playing field I have to go to objective data as the measure rather than feelings. The data I found shows many data points but there are two that I think are vital for people to understand:
I looked for any empirical data that would show traditional project management (Waterfall) beating Agile methodologies for software development. After several hours I gave up. I don’t know if it exists but if it does the data showing Waterfall beating Agile is very hard to find.
The exact opposite is true for Agile being better for software development than traditional project management. There were too many studies to include so i decided to focus on one of the key studies that would be most appealing to management. To that end, I found an excellent article written by Dr. David F. Rico, PMP, ACP, CSM entitled “The Business Value of Using Agile Project Management for New Products and Services” (http://davidfrico.com/rico-apm-roi.pdf). It is an extremely concise and well documented survey of data in support of Agile and is a “study of studies” that really summarizes the Agile impact. I suggest you read the entire article but below are the most compelling pieces of data showing improvement of Agile over traditional project management within several studies:
In the same article Dr. Rico also mentions the 2008 Maryland study that “[…]developed a database with over 153 data points on the costs and benefits of agile project management from 72 studies.” [Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? An analysis of extreme programming, testdriven development, pair programming, and scrum (using real options). TickIT International, 10(4), 9-18]:
Additionally, in 2009 there was another study that examined the “[c]ost and benefit metrics, models, and measures were developed based on 52 data points from 32 studies.” [Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing.]:
Naturally there are many, many more articles on the benefits of Agile. One other one that springs to mind is Ben Linder’s article entitled, “Evidence of Success of Agile Projects”. (http://www.infoq.com/news/2012/11/success-agile-projects). Linders cites references to other studies that have shown Agile project success as well as guidance for implementation. Feel free to add you own favorite study in the comments section and, if you have a study that shows Waterfall beating Agile I will gladly add it to the main article for balance.
Apologies for the delay on this one. I briefly toyed with the idea of retiring the blog and just letting the posts stand until someone else took up the mantle. After much thought I decided to continue but post as my schedule allows. With that said, it’s time for Visual Studio 2013!!! :)
On October 17th we made Visual Studio 2013 RTM available for folks to download. I’ll be covering/updating posts on the features going forward but I wanted to point out where you can find information today and talk about the launch coming up.
The official Visual Studio 2013 Launch will happen on November 13, 2013. You can go here for more information and join in the fun:
If you just want a quick overview of the new features you can go here:
Soma mentioned the release on his blog with some additional information, here is a piece of what he had to say:
“There are great new features and capabilities in Visual Studio 2013 for every developer, including innovative editor enhancements such as Peek and CodeLens, diagnostics tools for UI responsiveness and energy consumption, major updates for ASP.NET web development, expanded ALM capabilities with Git support and agile portfolio management, and much, much more.”
Brain Harry obviously also mentioned the release on his blog but really didn’t go into much detail:
The Visual Studio team pitched in with their thoughts which can be found here:
Of all the posts, the Office Team post had the most detail about new features in the release. They focused on Office features but I found the article very good and found out some things I didn’t know were available:
So I absolutely LOVE this release. The one defining feature for me is CodeLens (update coming soon) and I can’t say enough good things about the product features. With that said I have three things that deserve mention:
I’m still not sold on the need for signing into Visual Studio. The Visual Studio team explains this as enabling you to have the ability to synchronize settings across machines but, for me at least, this doesn’t seem a compelling enough reason to require the sign-in. You can decide for yourself by reading the post on synchronization here:
Here is the complete official list of benefits you get by signing in:
Synchronizes your Visual Studio settings – Settings that you customize, such as key bindings and color theme, apply immediately when you sign in to Visual Studio on any another device.
Permanently unlocks Visual Studio Express – You can use any edition of Visual Studio Express for as long as you like, instead of being limited to the trial period of 30 days.
Extends the trial period for Visual Studio – You can use Visual Studio Professional, Visual Studio Premium, or Visual Studio Ultimate for 90 days, instead of being limited to the trial period of 30 days.
Unlocks Visual Studio if you use a Microsoft account that's associated with MSDN – If your Microsoft account is associated with your MSDN account, your copy of Visual Studio is automatically unlocked.
Automatically connects to Team Foundation Service – You no longer need to enter credentials to connect to any of your team accounts for Team Foundation Service.
To be fair, not all SKU’s require a sign-in. The MSDN versions for Volume Licensing have a product key that can be used instead which makes sense when you are rolling out several thousand seats of VS.
This one totally slipped by me. It wasn’t until a customer mentioned the requirement that I truly realized the implications. Visual Studio 2013 RTM requires that you have IE10 in order to use it. (see image above) Here is where you can find the system requirements for the various SKU’s:
I am absolutely NOT a fan of this requirement. I talked with folks from the team and the reasoning for this is that the web features require IE10 components. That’s reasonable but the components should have been included with VS instead of requiring an install of IE10. I hope this requirement will change but, for now, this is our reality so be aware you will need to install IE10 in order to install VS2013.
I think there are four good reasons why a developer would move to VS103 Ultimate: CodeLens, CodeMap with Debugger Integration, Dependency Graphs, and IntelliTrace. A few people have mentioned that they feel CodeLens should be in all the SKU’s instead of just Ultimate. Here is my response to that line of reasoning:
“Your argument, for me at least, seems to be logically problematic. If we move a feature from Ultimate to Premium then why not move it from Premium to Professional? Why not from Professional to Express(Free)? Although you didn't say it, I've actually had a few people tell me we should give Ultimate away for free. My response is always the same: Would you, as a software developer, agree to work at your company for free? Regardless how you spin it, you work for money. You have to pay rent/mortgage, buy a car, and many other things that require you have an income.
We have many teams at Microsoft that work on Visual Studio. They devote their careers to making a great product and, like you, they need to eat, buy a car, and pay rent/mortgage. They spend a large amount of time deciding where features will land in order to best serve our customers. I personally think they do a great job at balancing features across the product lines while considering the company's financial needs. These are just my thoughts on the subject but I would ask that you keep this in mind when requesting features be moved or product be given away for free.”
Some people have agreed with me and some have disagreed:
“Just like many others, I'd like to point out that usability of this feature will somewhat hinge on its accessibility.
Seeing how Ultimate is prohibitively expensive for most small(ish) companies which usually buy just one or two Ultimate licenses for their architects, the rest of the crew getting Premium (at best) or Professional (most often it appears), I don't see this getting used much.
And please could we stop with the bullsh*t argument of Microsoft devs have to eat. I am quite sure that you do not live off of MSDN subscriptions, but from Windows sales, which in turn get boosted by the applications availability. Cheaper Visual Studio (or free), more applications will be available for Windows, hence more money for Microsoft (so that you can eat and pay mortgage).
Just look at other platforms (ahem, Apple with MacOSX to lesser extent and iOS to a much bigger extent) - how much do their tools cost? Nothing.”
The most notable position on the other side of this argument is from Keith Ward, Editor in Chief, Visual Studio Magazine in his article entitled, “Hey, Microsoft: Make CodeLens Available in Visual Studio 2013 Professional”:
“CodeLens is perhaps the best new feature of Visual Studio 2013.
Too bad you'll never get to use it.
That is, unless you have Visual Studio Ultimate. Those of you with Visual Studio Professional -- in other words, most of you -- or even Visual Studio Premium aren't eligible for the awesomeness that is CodeLens.”
I find it interesting that Keith does go on to say (emphasis part of the original text):
“Note that I didn't say it's wrong for Microsoft to keep CodeLens at the Ultimate level; it can do whatever it wants. It spent the time and resources building CodeLens, and it's perfectly justified in letting the market decide whether CodeLens is worth the price hike for enough devs. But Ultimate is more than double the price of Premium, its downstream neighbor. Absolutely, they get a lot more for their money with Ultimate, including more Windows Azure credits. But I do think it's short-sighted: since most developers can't afford it no matter what goodies it has, it's immaterial to them.”
I would say that each person needs to decide if the benefits outweigh the costs but, while I often disagree with the VS team on many things, the decision to put CodeLens in Ultimate is something I am completely behind.
So in my quest to find new and interesting interfaces for TFS, my buddy Chris Koenig introduced me to this little gem. It’s geared for the non-developer roles who want a nice, friendly look and feel to work items. Check it out for yourself here:
Here is some information verbatim from the site:
WorkItem Glass is an alternate client for Team Foundation Server whose target audience consists of those team members not in a traditional Developer role such as Quality Assurance, Project Manager and Business Analyst. WorkItem Glass provides a Smart View into Team Foundation Server projects, hosted on tfs.visualstudio.com, by emphasizing relationships between work items. WorkItem Glass will need your account alternate credential information for your TFS repository hosted on tfs.visualstudio.com.
Myfriends at Caravan Studios <www.caravanstudios.org>,the newest division of TechSoup <www.techsoup.org>You can go here for more information:
Once you've registered with SafeNight, you become a member of the community. A community who believes that people want to help. That we can use the resources at our disposal to make change. A community that believes everyone deserves a violence free life.
Once you've registered, you can connect to a verified domestic violence service organization. These organizations provide shelter and other services to individuals in need. Once you connect, you will receive requests to sponsor a hotel room when there is an urgent need and no availabe space at a shelter.
When the organization you are supporting needs help, you will see a notification on your phone. That lets you know that there is an individual who needs a safe night. By agreeing to sponsor a hotel stay, you give that person a chance to receive additional support in a time of need.
You can quickly and easily cut or delete the current line. Just do one of the suggestions below.
Begin any operation by placing your cursor anywhere on the line:
Use CTRL + L to cut only the text on the line without the carriage return at the end.
Or use SHIFT + DEL or CTRL + X to cut the line and the carriage return at the end.
If you want to DELETE the line instead you can use CTRL + SHIFT + L.
Ever cut something then accidentally cut a blank line? I can't really think of a good reason to cur or copy a blank line and yet you are still allowed to do it.
The good news is you can keep this from happening by simply going to Tools -> Options -> Text Editor -> All Languages -> General and deselecting the "Apply Cut or Copy commands to blank lines when there is no selection" checkbox:
Note: This will prevent using Shift+DEL to delete an empty line so you will have to enable the feature if you use Shift+DEL.