Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

  • Buck Hodges

    Authentication in web services with HttpWebRequest


    Hatteras has three tiers: client, middle, and data.  The middle tier is an ASP.NET web service on a Windows 2003 Server running IIS 6.  When the client (we use C# for both it and the middle tier) connects to the middle tier, it must authenticate with IIS 6.  Depending upon the IIS configuration, that may be negotiate, NTLM, Kerberos, basic, or digest authentication.  Here's a page on Internet Authentication in .NET.

    NOTE:  The code below uses the .NET 2.0 framework (Visual Studio 2005).

    In order to authenticate, the client must have credentials that the server recognizes as valid.  For Windows Integrated Authentication (comprising NTLM and Kerberos) using the current logged-on user, the client can use CredentialCache.DefaultCredentials.  Here's how it looks in code.

    using System;
    using System.IO;
    using System.Net;
    class Creds
        public static void Main(string[] args)
            Uri uri = new Uri(args[0]);
            HttpWebRequest req = (HttpWebRequest)WebRequest.Create(uri);
            req.Credentials = CredentialCache.DefaultCredentials;
            // Get the response.
            using (HttpWebResponse res = (HttpWebResponse)req.GetResponse())
                StreamReader sr = new StreamReader(res.GetResponseStream());

    You can find that same type of sample code in MSDN.  However, it gets more interesting if you want to use basic or digest authentication or use credentials other than the current logged-on user.

    One interesting fact is that the HttpWebRequest.Credentials property is of type ICredentials, but it only uses instances of NetworkCredential and CredentialCache.  If you implement ICredentials on your own class that is not one of those two classes, you can assign it to the Credentials property, but HttpWebRequest will silently ignore it.

    To go further, we need to look at the CredentialCache class itself.  This class is used to hold a set of credentials that are associated with hosts and authentication types.  It has two static properties, one of which we used above, that are the "authentication credentials for the current security context in which the application is running," which means the logged-on user in our case.

    The difference is very subtle.  The documentation for DefaultCredentials says, "The ICredentials instance returned by DefaultCredentials cannot be used to view the user name, password, or domain of the current security context."  The instance returned by DefaultNetworkCredentials, being new in .NET 2.0 and of type NetworkCredential, would presumably let you get the user name and domain, but it didn't work for me when I tried it with the following code (UserName returned an empty string).

    Console.WriteLine("User name: " + CredentialCache.DefaultNetworkCredentials.UserName);

    The NetworkCredential class implements both the ICredentials (NetworkCredential GetCredential(Uri uri, String authType)) and ICredentialsByHost (NetworkCredential GetCredential(String host, int port, String authType)) interfaces.  The ICredentialsByHost interface is new in .NET 2.0.

    The CredentialCache class has methods that let you add, get, and remove credentials for particular hosts and authentication types.  Using this class, we can manually construct what setting req.Credentials = CredentialCache.DefaultCredentials accomplished in the original example.

            CredentialCache credCache = new CredentialCache();
            credCache.Add(new Uri("http://localhost"), "Negotiate",
            HttpWebRequest req = (HttpWebRequest)WebRequest.Create(uri);
            req.Credentials = credCache;

    The authentication type can also be explicitly specified as "NTLM" and "Kerberos" in separate calls to Add().  This page on authentication schemes explains using Negotiate as follows.

    Negotiates with the client to determine the authentication scheme. If both client and server support Kerberos, it is used; otherwise NTLM is used.

    Let's say you want to work with basic or digest authentication.  The documentation for CredentialsCache.DefaultCredentials and CredentialsCache.DefaultNetworkCredential says that neither will work with basic or digest.  If we add basic to credentials cache, we get a runtime exception.

            credCache.Add(new Uri("http://localhost"), "Basic",

    The exception is thrown by the Add() method.

    Unhandled Exception: System.ArgumentException: Default credentials cannot be supplied for the Basic authentication scheme.
    Parameter name: authType
    at System.Net.CredentialCache.Add(Uri uriPrefix, String authType, NetworkCredential cred)

    So, in order to use basic or digest, we must create a NetworkCredential object, which is also what we need to do in order to authenticate as some identity other than the logged-on user.  To do that, we create NetworkCredential object and add it to the CredentialCache as follows.

            credCache.Add(new Uri("http://localhost"), "Basic" /* or "Digest" */,
                          new NetworkCredential("me", "foo", "DOMAIN"));

    Basic authentication sends the password across the wire in plain text.  That's okay for a secure connection, such as one using SSL, and for situations where you don't need much security.  Digest authentication hashes the password along with other data from the server before sending a response over the wire.  It's a significant step up from basic.

    Now we need to have the user name and password to create the NetworkCredential object.  There are two parts to this.  First is prompting the user for the name and password.  The second is storing the information.  For prompting there is the Windows dialog that pops up any time you go to a web site that requires authentication.  That dialog includes a "Remember my password" checkbox.  I don't yet know what the managed API is for that.

    To store and retrieve the information, there is the new managed DPAPI explained by Shawn Farkas in several blog postings.

    [Update 3:44pm]  The Windows dialog used when IE prompts for name and password is created by the CredUIPromptForCredentials() function.  CredUIConfirmCredentials() is used to save credentials that authenticated successfully, if desired.  Duncan Mackenzie's MSDN article Using Credential Management in Windows XP and Windows Server 2003 explains how to use it from .NET.

    [UPDATE 4/10/2006]  I updated the MSDN links that were broken.

  • Buck Hodges

    The story on why Team System is not in Beta 1


    Someone on the newsgroups asked for an official answer on why Team System is not in Whidbey Beta 1.  The short answer is that it's not beta quality, so it didn't belong in a beta.  Keep your eyes open for another CTP release in the next few months.  The current plans for this upcoming CTP are for it to include the server portions of Team System that were not in the May release.

    Rick LaPlante personally replied to the post with the following answer.

    While Paul provides a skeptical, yet possible explanation, as I made the decision, I'll tell you what the real logic was. 

    CTPs (community technology previews) are about getting bits out regularly to customers for early feedback and discussion.  With this release of VS, we are trying to be more open about what we are building and give earlier access to folks to the bits.  By definition, these bits are basically stable builds from our own source trees with minimal additional quality checks built into the process.  They are <NOT> beta quality.  they are interim builds.  As such, it was appropriate to put parts of the Team System into the CTP because we met the quality bar and certainly needed to start getting feedback asap about the feature set and implementation.  As Paul correctly points out (and we've said many times) the Team System is not currently at beta quality and as such we did not include it in Beta 1 of VS.  We will have another CTP in the next few months based on the VS Beta 1 bits that will include the Team System (again not a beta quality build, but expected to be much better than the May CTP) and then follow on with VS Beta 2 which will contain a full, beta quality version of the Team System.

    Hope this answers your question.

  • Buck Hodges

    May CTP to appear again


    The May 2004 CTP that contained Team System (but not Team Foundation, which includes source control and work item tracking) is supposed to be up on MSDN by Monday.  There were a number of requests for it in the newsgroups after it was mistakenly removed from MSDN.

  • Buck Hodges

    Scoble is everywhere


    I got the July issue of Triangle TechJournal and opened it up to find an interview of Robert Scoble by Andy Beal (the interview doesn't appear to be on the web site yet). So even my mail box has been Scobleized.

    Among other things, he mentions taking 7400 pictures over the last 18 months.  Even for digital, that seems like a lot.  I wonder how Longhorn compares to one of the many apps on the market for organizing the pictures (giving both the same metadata of course)?

  • Buck Hodges

    Out for the week

  • Buck Hodges

    TechEd C# presentations

    Duncan Mackenzie just posted a link to the C# TechEd 2004 page that has slides from some of the presentations (more to come).  Cool!
  • Buck Hodges

    VSTS pricing


    There have been questions about pricing in the newsgroups.  Here is what Raju Malhotra had to say about it.  As I understand it, many of the pricing details have yet to be worked out and are far from being set in stone.

    We will share the specific pricing details with you as soon as they are finalized but here is what we know. Hope this helps.

    MSDN Universal customers will have an option to get any one of the VS Team Architect, VS Team Developer or VS Team Test products as part of their subscription without paying anything extra as long as their subscription is current at the release time. Of course, all other benefits of their subscription like monthly shipments, access to subscriber download site, MS servers for dev/test purposes, etc. will continue as usual. They will also be able to migrate to the full suite (including all three of the above prducts) at an additional price to be announced later. In general, the pricing for VS Team System products will be competitive with the lifecycle tools market.

    We will also have upgrade paths available in retail. We are currently working on the upgrade eligibility and specific pricing for that.

    Please stay tuned for more details.

    Raju Malhotra
    Product Manager,
    Visual Studio Team System

  • Buck Hodges

    Interfaces for the TFS source control client


    The new source control system in Team Foundation will have several client interfaces.

    Command line   The command line interface provides a complete set of commands for performing all of your source control tasks.  When run interactively (i.e., the /noprompt option is not specified), some commands will bring up dialogs.  These commands include workspace for defining editing workspaces, history, resolve, checkin, and a few others.  If you use the built-in diff tool or configure your own (Beyond Compare, Araxis, etc.), the diff command will bring up GUI diff window.  Scripts will use the /noprompt option to suppress dialogs, as well as those who don't want a GUI.

    Visual Studio   The Visual Studio Team Foundation source control integration will far exceed the level of functionality available in prior versions.  Without opening a solution, you'll be able to browse the repository, create and manage labels, view history, open a solution, etc.  It's intended to provide a level of functionality similar to what exists in the Visual SourceSafe Explorer.  Once you open a solution, files will be automatically checked out when you edit them, you'll see a list of pending changes in the checkin window, you'll be able to associate work items (bugs) with the changes, establish checkin policies, and add notes to each checkin.

    Visual Studio Shell   This interface will be the Visual Studio GUI but without all of the compilers, debuggers, profilers, etc.  It's intended to provide the source control, work item tracking, and other parts of the Team System GUI without the coding tools, resulting in a much smaller footprint for users who need access to Team System but aren't writing code.

    There is also a client API, written in .NET, for writing applications to perform source control operations.  The client API is used by the command line and Visual Studio integration as well.


  • Buck Hodges

    A simple example using branch and merge


    Merge is an overloaded word. There is a content merge and then there is a branch merge. A content merge is where you have edited a file and someone checked in a newer file, so the source control system will tell you to do a content merge before checking in the file (if it's interactive, it's a 3-way merge GUI).

    A branch merge is migrating changes from one branch to another. If a source branch A has a file rock.cs that had been edited and file scissors.cs that had been deleted, merging these changes into a target branch B would result in a pending edit on file rock.cs and a pending delete on the file scissors.cs in the target.

    Here's a simple example that uses the command line.  The biggest differences between this and a “real-world“ example are the number of files involved (you may have thousands) and that you would probably have conflicts for a subset of the files (e.g., the same file was edited both in the source and in the target, resulting in the need to do a 3-way content merge).

    The /i option is the shortcut for the "noprompt" option that makes everything non-interactive, as would be needed in batch script. Changes are committed in change sets, and the whole check in either succeeds or fails (it's atomic).

    1. Create a workspace and add the files mentioned in the merge explanation above.

    D:\project>h workspace /i /new MyProject
    D:\project>h add /r A
    D:\project>h checkin /i
    add A
    add rock.cs
    add scissors.cs
    Change set #4 checked in.
    2. Create a branch from A to a target B.
    D:\project>h branch A B
    D:\project>h checkin /i
    branch B
    branch rock.cs
    branch scissors.cs
    Change set #5 checked in.
    3. Now we have A and B in the repository, related by B being a branch of A.
    D:\project>h dir /r
    6 item(s)
    4. The branches command shows that B is branched from A.
    D:\project>h branches A
    >> $/A <<
         $/B Branched from version 1
    5. Now we edit rock.cs and delete scissors.cs in the source branch.
    D:\project>h edit A\rock.cs
    D:\project>echo new line >> A\rock.cs
    D:\project>h delete A\scissors.cs
    D:\project>h checkin /i
    edit rock.cs
    delete scissors.cs
    Change set #6 checked in.
    6. Merge the changes made in branch A over to branch B. Of course in a real project, there may be conflicts to resolve (rock.cs may have been edited both in the source and target, which will need to be merged with a 3-way content merge), and the developer may need to make additional changes in B (for example, B may be a newer release of the project and the code may be need to be changed due to an API change made earlier in B).
    D:\project>h merge A B
    merge, edit: $/A/rock.cs;C5~C6 -> $/B/rock.cs;C5
    merge, delete: $/A/scissors.cs;C5~C6 -> $/B/scissors.cs;C5
    D:\project>h checkin /i
    merge, edit rock.cs
    merge, delete scissors.cs
    Change set #7 checked in.
    6. In the history, we see that B\rock.cs was created by branching in change set 5 and then an edit was merged in change set 7.
    D:\project>h history /i B\rock.cs
    Vers Date       Chngset User          Change Type          Files
    ---- ---------- ------- ------------- -------------------- --------------------
       2 06/14/2004       7 buckh         merge, edit          $/B/rock.cs
       1 06/14/2004       5 buckh         branch               $/B/rock.cs
  • Buck Hodges

    More on branching and merging vs. sharing and pinning


    Branching and merging in TFS provide a more robust way to accomplish what sharing and pinning are often used for in VSS.  In TFS, you would branch a directory (source), using the "branch source target" command, to the desired location (target).  Then when there are changes in the source that you need in the target, you would use the "merge source target" command to propagate the changes.  The merge command remembers what changes have have been brought over to the target, so it brings the target up to date with the source by only merging changes that have not been merged.

    The merge command will pend edits, branches for files added, deletes, etc. in the target (in TFS, commands pend changes and then the checkin command submits all changes in a single atomic operation).  After running the merge, command you would then build the software and test it.  Additional changes may need to be made in the target, such as when you change a function or method signature.  When everything is ready, you would check in the merged changes, along with any other changes you needed to make, in a single atomic operation.

    By doing this, you are able to build and verify before checkin each branch when it merges in the changes from the source.

    There is no penalty in TFS with respect to having multiple branches of the same file.  In the SQL database, they all reference the same content.  Only when a branched file changes does new content get added.

    With respect to merging binary files, there is nothing to do except run merge followed by checkin if the binary files in the target do not change.  If binary files in the target have changed, the merge command will produce conflicts for those files, and you would have to pick which to keep (source or target -- there is no 3-way content merge option, of course) when resolving the conflict.

    If you want to have every project always use the same same file and immediately see new versions as soon as they are checked in, putting the file in a common location in the TFS repository, such as $/public/bin/dlls, is the way to go.  That does mean that everything that references it should use relative paths.  And since there is no isolation, everything that depends on the file must be checked prior to checkin, or you run the risk of silently breaking other projects (i.e., it requires manual coordination).

  • Buck Hodges

    When can I get the Team Foundation Server?


    Several people have asked this question.  The server is not included in the May Community Preview distributed at TechEd.  Also, the server bits will not be included with the upcoming VS 2005 Beta 1 release.  In fact, none of Team System will be in Beta 1, so the May Community Preview release at TechEd is it for a little while.

    The server will be available in a Team System community drop later this year.

  • Buck Hodges

    Migrating from SourceSafe to Team Foundation Server


    We plan to provide migration tools for users switching to TFS.  A VSS user asked in the newsgroup about migrating VSS labels, revision history, sharing, and pinning.

    The goal is migration of all data, consisting of projects, files, and folders, with associated metadata reliably with minimal information loss while preserving user information and appropriate permissions.  There are some features in VSS that do not translate to TFS.  The following is quick overview of the preliminary plan.

    • Users and groups in TFS are Windows accounts (it uses standard NTLM authentication).  SourceSafe identities will be migrated to Windows accounts. 
    • Labels and revision history will be preserved.  With regard to revision history, TFS supports add, delete, rename/move, etc.  It does not support destroy/purge in V1.
    • TFS does not have the equivalent of sharing, so the current plan
      is that the migration tool will handle that by copying.  Each copy will have its own history of the common changes made after the file was shared.  VSS branching is migrated in a similar fashion.
    • Pinning and unpinning are also not available in TFS.  The current plan is that for any item currently pinned, the user will be given the option to either ignore the pinning or to assign a label to the versions that are pinned and lock them.
    • TFS does not support the VSS archive and restore features.

    That is a very quick summary of the plan, which may change.  We welcome your feedback.

  • Buck Hodges

    12 GB CompactFlash card


    Of course you can get microdrives, but if the moving parts make you nervous, Pretec offers a 12 GB flash card.  It's only $14,900.  Then you'll need a $60,000 digital camera to go with it.  Somehow that nifty $3,000 Nikon D2H just seems inadequate.


  • Buck Hodges

    VSTS Newsgroups

    The VSTS 2005 page mentions the newsgroups for VSTS (in the Community Resources section beside the "Ask the Team" column). It doesn't stand out, though, and so a lot of people may not realize they are there. The newsgroups are actively monitored by a large number of VSTS folks, so it's a great way to interact and provide feedback (you'll usually get a quick reply to any question you post there).

    You can read the newsgroups just using your browser at http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slcid=us. The browser interface isn't very good for keeping up with the newsgroups, though.

    Viewing these Newsgroups with an NNTP Newsreader 

    You can use Outlook Express or other NNTP newsreader.  Since these are private newsgroups, your server will require you to logon using the following information:

    • Server: privatenews.microsoft.com
    • Account name: privatenews\VSUser
    • Password: Password
    • Note that the password is case-sensitive.
    Here is the list of the newsgroups with rough descriptions.
    • Microsoft.private.whidbey.teamsystem.general - VSTS overall
    • Microsoft.private.whidbey.teamsystem.architect - modeling and design tools (Whitehorse)
    • Microsoft.private.whidbey.teamsystem.architect.appdesign - Whitehorse app designer
    • Microsoft.private.whidbey.teamsystem.architect.deployment - Whitehorse deployment designer
    • Microsoft.private.whidbey.teamsystem.developer - developer tools (PreFast, FxCop, Perf tools)
    • Microsoft.private.whidbey.teamsystem.developer.classdesign - Whitehorse class designer
    • Microsoft.private.whidbey.teamsystem.tester - testing tools
    • Microsoft.private.whidbey.teamsystem.projectmanager - project management tools
    • Microsoft.private.whidbey.teamsystem.teamfoundation - source control, change management, work item tracking
  • Buck Hodges

    Branching models


    Doug Neumann, our PM, posted on the Team Foundation newsgroupmicrosoft.private.whidbey.teamsystem.teamfoundation newsgroup a nice answer to a question about branching models and VSTS.

    Question (Carl Daniel):

    IEEE Computer, September 2002 issue contained an article entitled "the importance of branching models in SCM". Since we can't really evaluate the Team System SCM without the server component, perhaps someone from the Team System team at MSFT could comment on how Team System SCM fits into thebranching scenarios described in this article.

    The article is also available at http://www.seapine.com/pub/papers/SCMBranchingModels.pdf in case you don't have IEEE Computer handy.

    Answer (Doug Neumann):

    That's a good article, thanks for the pointer.

    The answer to your question is that we give you the tools to implement any of the models outlined in this article.

    Here's a quick overview of the power of branching and merging in the VS Team System:

    * Path-space branching -- branches are created within the path structure of the repository, similar to file copy operations. In talking to users, we find that this model is much easier to visualize, and is actually what they really want to do. They want a copy of the source that can evolve asynchronously and that's what we give them.

    * Support for merging namespace changes -- many SCC systems focus on merging content changes that have occurred to a specific file between 2 branches. We take a broader view of merging changes and focus on merging all types of changes between branches. Thus, we're able to merge file adds, deletes, moves, renames, etc. as part of your standard merge operation.

    * Changesets -- changes that are committed together are managed as a single entity called a changeset. Thus, when it comes time to merge a change to a new branch, you don't have to wrack your brain trying to figure out the full list of files you need to operate on. Just tell us which changeset you want to merge and we'll do it all for you.

    * Cherry-pick merges -- you can merge specific file change to another branch without merging the changes that were included in previous versions of those files. Thus, if you've got 2 bug fixes which touch the same file, you can merge the second one without merging the first.

    * Merge candidate queries -- you can ask the system for a list of all changes which haven't yet been merged between 2 branches.

    * Merge history queries -- you can ask the system for a list of all changes that have ever been merged between 2 branches.

    The authors of this article seem rather partial to their "Branch by Purpose" model, so let's talk about how that would work in the Team System.

    We'll setup a mainline for most of our development work and put it in the repository at $/Application/Main. During the development phase, all of our new features and bug fixes are going into this line. When we are feature complete, we branch the main line to work on one or more release branches. To keep it simple, let's say we've got a single release branch which we'll put at $/Application/Release. If we have other feature work that we want to occur in parallel, we could also branch the main line to create a bridge branch at $/Application/Bridge.

    After feature complete, we enter the "code chill" mode where we're only submitting bug fixes to the main line. We have some cool mechanism in VSTS that will allow you to control what changes can get checked into the mainline during this period (if you want to hear about those, post another follow-up). At any time, we can run a query to get a list of all changesets that have been committed to the main line but not merged to the release branch. We can then cherry-pick those changes as necessary (we don't have to take them all) or merge over all changes if desired.

    When we stabilize that release line, we enter code freeze at which point release candidates are produced. According to the article, any fixes needed for the release candidate are checked directly into the release branch, although I don't see why they couldn't also follow the model of code chill. Either way, you can merge the changes either direction between the main line and the release branch to make sure the fix is in both places.

    In the article, they branch for the actual release, but they don't show any changes on this branch. If it's not going to evolve, you can accomplish the same goal by slapping a label on the items that were included in the release. If you determine later on that you need to make changes to the release, you can always create the new branch from the label. If you're going to be releasing hotfixes for individual bugs, you might want to branch for each hotfix and then merge the changes back into the release branch (where your maintenance work is happening).

    Hope that helps. Post a follow-up if you'd like more detail. Also, I'd be interested to hear what you think of the strategies in this article. I have my own philosophy on this stuff that I'll save for another time.

  • Buck Hodges

    Dev303 summary, more blogs


    Thanks to Rob Caron there are good notes on Brian Harry's presentation.

    DEV303 - Visual Studio Team System: Enterprise-Class Source Control and Work Item Tracking

    Kevin Kelly (also in North Carolina) has started a weblog, opening with “Why Work Item Tracking?”  Ask him if they can add make work items blogs. Or maybe all work items should be blog entries, and products would be blogs.  Then you could subscribe to the bug feeds for your stuff.  :-)

    Blogging in DevDiv continues to reach new heights.  With his opening "Hello, World" post, S. "Soma" Somasegar, corporate vice president of the Developer Division at Microsoft Corporation, has provided you a direct link to the top.

  • Buck Hodges

    Brian Harry's weblog


    So Korby's gotten Brian going.  Check out “A little history on me and the Visual Studio Team System” for how we got here.

  • Buck Hodges

    Summary of Doug's Managing Software Configurations presentation


    Korby Parnell, our checked-in tech writer, has posted a great summary of Doug's Managing Software Configurations presentation.  He even included highlights from the Q&A.  Check it out and add your comments.

    Rob Caron posted a picture of Doug in action.

  • Buck Hodges

    Doug Neumann on Software Configuration Management with Burton

    Doug's the program manager for Source Control in Visual Studio 2005 Team Server, and his talk will look at doing details of software configuration management with VSTS. Doug's and Brian's talks cover different ground and will really give you a feel for what we're doing.
    DEVC32 How-To: Managing Software Configurations with Visual Studio 2005
    Wednesday, May 26 2:00 PM- 3:15 PM, Cabana 06
    Speaker(s): Douglas Neumann
    Track(s): Developer Tools and Technologies
    Learn about the strategies for working with and managing configurations of source code with Visual Studio 2005. See how branching, merging, and labeling can be applied to implement several standard SCM practices and help you choose the practice that best fits your software development processes.
  • Buck Hodges

    Visual Studio 2005 Team System (aka Burton)

    The official web site for Visual Studio 2005 Team System is now live, including a Burton blog called AskBurton. I am a developer working on the Burton source control system (Team Foundation), which we code-named Hatteras. Over time I plan to add details about Hatteras and how it works. Here is a good description of Team Foundation from the Team Development page.
    Visual Studio Team Foundation provides integrated source control, work item tracking, reporting, and custom policies that enable your team to efficiently manage change in your software development projects. The components of Team Foundation include work item tracking, source code control, policy support and notifications, and report generating capabilities. By integrating these change management components seamlessly, we unobtrusively inject SCM process and team-specific requirements into the developer’s daily workflow.
    If you are at TechEd, be sure to see presentations by Brian Harry, our product unit manager (PUM), and Doug Neumann, our program manager for Burton source control.
    DEV303 Visual Studio 2005 Enterprise Tools: Enterprise-Class Source Control and Work Item Tracking
    Thursday, May 27 3:15 PM- 4:30 PM, Room 20D
    Speaker(s): Brian Harry
    Track(s): Architecture, Developer Tools and Technologies
    Get an introduction to the new software configuration management system included in the Visual Studio 2005 enterprise tools. See how an integrated and extensible source code control and work item tracking system can boost your team's productivity by significantly streamlining your development processes.
    Hatteras Island, with its famous lighthouse, is part of North Carolina's Outer Banks.
  • Buck Hodges

    Converting a text file from one encoding to another


    The .NET framework handles file encodings very nicely.  Not too long ago, I needed to convert files from one encoding to another for a library that didn't handle the encoding of the original file.  Since someone on an internal alias asked about doing this a couple of weeks ago, I thought it would be useful to post it here.

    The .NET runtime uses Unicode as the encoding for all strings.  The StreamReader and StreamWriter classes in System.IO take an Encoding as a parameter.  So, to convert from one encoding to another, we just need to specify the original encoding and read the file contents into a string followed by writing out the string in the desired encoding.

    The Path class, also in System.IO, provides us with an easy way to create temporary files in the Windows temporary directory.  We can write the results to a temporary file so that if anything goes wrong, the destination file is not overwritten.  Also, it allows the conversion to work when the source and destination are the same file.

    StreamReader allows us to read the source file in blocks so that we don't have any size limitations on the file that need to convert.

    The Main() method below is just a trivial wrapper to call the ConvertFileEncoding()since it wasn't oringally a standalone app.

    // Example: convert test.cs test-conv.cs ascii utf-8

    using System;
    using System.IO;
    using System.Text;
    public class Convert
        public static void Main(String[] args)
            // Print a simple usage statement if the number of arguments is incorrect.
            if (args.Length != 4)
                Console.WriteLine("Usage: {0} inputFile outputFile inputEncoding outputEncoding",
            ConvertFileEncoding(args[0], args[1], Encoding.GetEncoding(args[2]),
        /// <summary>
        /// Converts a file from one encoding to another.
        /// </summary>
        /// <param name="sourcePath">the file to convert</param>
        /// <param name="destPath">the destination for the converted file</param>
        /// <param name="sourceEncoding">the original file encoding</param>
        /// <param name="destEncoding">the encoding to which the contents should be converted</param>
        public static void ConvertFileEncoding(String sourcePath, String destPath,
                                               Encoding sourceEncoding, Encoding destEncoding)
            // If the destination's parent doesn't exist, create it.
            String parent = Path.GetDirectoryName(Path.GetFullPath(destPath));
            if (!Directory.Exists(parent))
            // If the source and destination encodings are the same, just copy the file.
            if (sourceEncoding == destEncoding)
                File.Copy(sourcePath, destPath, true);
            // Convert the file.
            String tempName = null;
                tempName = Path.GetTempFileName();
                using (StreamReader sr = new StreamReader(sourcePath, sourceEncoding, false))
                    using (StreamWriter sw = new StreamWriter(tempName, false, destEncoding))
                        int charsRead;
                        char[] buffer = new char[128 * 1024];
                        while ((charsRead = sr.ReadBlock(buffer, 0, buffer.Length)) > 0)
                            sw.Write(buffer, 0, charsRead);
                File.Move(tempName, destPath);
  • Buck Hodges

    Bill Gates' visit to the University of Illinois


    I didn't realize that Microsoft hires more computer science graduates from U of I than any other school.  It's a great school with a lot of bright people (I don't miss the cold January days, though).

    Bill Gates, the chief software architect for Microsoft, chose Illinois for his first stop on a three-day, five campus tour to promote computer science and engineering to students. Illinois is the only public university that is part of this tour. His February 24th talk, titled “Software breakthroughs: Solving the toughest problems in computer science,” was designed to highlight work being done at Microsoft, universities and research labs around the world.

    If you click on Help->About Internet Explorer, you'll see a couple of references to Illinois.

    Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign.
    Distributed under a licensing agreement with Spyglass, Inc. [Champaign, IL]

  • Buck Hodges

    Download the VC++ Toolkit


    Three weeks ago the Microsoft Visual C++ Toolkit 2003 was made available as a free download.  It's the full optimizing compiler.  That's pretty cool.  It doesn't include the IDE, though people have used it to replace the non-optimizing compiler in the VS Standard edition.

Page 23 of 23 (573 items) «1920212223