I read somewhere(?) that they where running Perforce with some internal tooling built on top of it.

I saw/heard that as well (hopefully someone can come up with the link). Things like Windows/Office apparently are in a custom perforce.

I believe that they do use TFS on a lot of the internal projects though and that Visual Studio is now done in TFS.

The following is a presentation in 2008 by Richard Erwin of Microsoft at the BCS CMSG (Configuration Management Specialist Group):

http://bcs-cmsg.org.uk/events/e20081124/2008-11-24-agile-scm...

Lots of good stuff there, but a key one is slide 8. In the question session Richard confirmed that Source Depot (the custom version of Perforce) was at that time still used for the source management although TFS was used for bug tracking etc for Office and Windows.

Don't know what has happened in the intervening years...

Here is a link about TFS use inside Microsoft: http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/t...

Apparently they use several large TFS instances.

This is correct.

http://programmers.stackexchange.com/a/85891

We eat our own dog food, most teams have moved over to TFS by now. I don't know about the larger orgs (Windows, Office) but for smaller groups TFS is how it is.

MS doesn't have a unified build environment, every team generally does their own thing. It has its pluses and minuses.

Shared code would occasionally be useful at Microsoft, but not as often as you'd think. Generally when relying on another team's code, it is preferred to take it as a binary drop when they do a product release, just like any other customer. This helps prevents needing to deal with churn in one's dependencies.

> We eat our own dog food.

Except for that whole ".NET framework" thing.

I'd say 70% of the projects I know about in MS use .NET.

All web sites are of course written in ASP.NET. Giant portions of the Xbox Live service are written in .NET. Heck lots of tools and utilities are also .NET based.

Is someone going to rewrite IE in C#? Not likely, that isn't what C# is for.

I think that sentiment comes from Microsoft saying back in the day (if I remember right) that they were going to rewrite much of their user software (such as MS Office) to use .NET.

Exactly. I doubt there's a single piece of .NET client-side software that a non-geek has heard of (Word, IE, paint, etc.).

Microsoft uses .NET a-plenty. Saying that brief marketing hype of over a decade ago isn't lived up to is a bit disingenuous. MS ships numerous apps in C#. Check out the Windows Store and WP Store, I know for a fact lots of MS's stuff in there is C# based. I cannot say for sure what Desktop apps are C# based because, well, it isn't exactly obvious!

C# isn't being used as a systems programming language, but it isn't meant to be one. (That said, I've written high performance code in C# before, you have to know what you are doing and understand your GC, same as writing high performance code in Java!)

Tons of LOB software internal to MS (indeed I'd say the vast, vast, majority of internal LOB software) uses C#. Lots of plugins and extensions to various tools use C#, and I wouldn't be surprised if lots of the PowerShell Cmdlets and Modules are C# based.

Now I have worked on a number of commercial projects that were written in C#, but of course I am unable to discuss them!

(None of this is spoken of as an official MS employee of course, it is not but my own opinions!)

I bet you must have a lot of experience with TFS...

Does it support not checking-out files that were edited but did not change in the end or you still have to revert them manually?

I think VS2012 and "local workspaces" fixed that.