While he’ll be speaking at a lot of user groups and Microsoft events in various cities, places are filling up fast.  However there is still some availability in a few cities.  If you are nearby or know someone who is then I encourage you to register and come along.

Austin TX

• Monday April 4 (Information)

Minneapolis

• Wednesday April 6 (Details soon)

Chicago

• Thursday April 7 2:00pm – 4.30pm (Register)
• Thursday April 7 6:30pm - 8:30pm (Register)

Milwaukee

• Friday April 8 9:00am – 11:30am (Register)

Well, I’m proud to say that we’ve continued the tradition and you can now use Team Explorer Everywhere with CodePlex.  Simply download the trial edition of Team Explorer Everywhere and then enter the license key given on the CodePlex wiki.  Note that if you already have a full license to Team Explorer Everywhere (either through retail, volume licensing or MSDN) then you can obviously use this to access CodePlex as well.

Just a quick tip.  When adding the connection, be sure to hop over to the Advanced tab to ensure that you do not have “tfs” in your path.  CodePlex has it’s TFS servers at the root of the server location (as required by older TFS clients and older versions of TFS) – but the Team Explorer Everywhere client will default to the TFS 2010 convention of looking at https://servername/tfs unless you tell it differently.  Also some of SSL certificates on some of the CodePlex servers are signed by a root certification authority that is not in the Java Certificate Store in all Java Runtime Environments running today.  If you run into this problem and you are having SSL issues then you can add the root CA to your Java certificate store.  An easier way is to un-check the “Accept only trusted SSL certificates” which will disable the root certification authority check for the SSL connection to the CodePlex server – but bear in mind that reduces the security of the communication between your machine and the CodePlex server.

Let me know how you get on.  I’m excited to see who takes us up on this offer.  As an encouragement, I’ll send a free copy of my book to the first person who emails me a screenshot of them contributing to a project on CodePlex using Team Explorer Everywhere.

Team Explorer Everywhere contains the following components:

• Team Foundation Server plug-in for Eclipse
• Cross-platform command-line client for Team Foundation Server
• Visual Studio Team Explorer 2010

I’ll post more about what functionality is included in this release, but first I wanted to talk about what this means to existing Teamprise customers.

Teamprise customers should have already got a couple of emails from the company. If you haven’t then head on over to the following site for more information (http://www.microsoft.com/pathways/teamprise).  Basically when Microsoft shipped it’s first release, Teamprise ceased sales of the existing products and will begin the process of wrapping up the company.  Microsoft will be the contact point from now on for all purchases and support enquiries.

Teamprise 3.0 customers are entitled to a free upgrade to the new Team Explorer Everywhere 2010 version.  You can find out the full details of eligibility and how to claim this license at the following page on the pathways site (http://www.microsoft.com/pathways/teamprise/Teamprise%20v3.x.htm).

If you are a new customer, you’ll be please to know that Team Explorer Everywhere is now also included in the Ultimate level MSDN subscription and is also available as a standalone product for folks without the top tier MSDN Subscription (or indeed without any MSDN Subscription).

If you have any questions of feedback about all this then the pathways site has contact details.  You can also discuss things over on our MSDN Forum.

Working on Teamprise has un-doubtably been the highlight of my career prior to joining Microsoft, and I have to confess to at having a tinge of sadness that the brand we created in our little start-up is going away.  That said all the developers who worked on the product came over to Microsoft and were part of the team that got this new release under the Microsoft banner out the door.  We all worked long hours to ensure that the new version was able to take advantage of many of the TFS 2010 features and I’m very proud of what we managed to accomplish since November.  Also, we’re obviously not stopping there.  Since shipping the initial release we’ve continued development and are hoping to keep getting more functionality out the door.  In addition, now that we are part of the core Team Foundation Server team we get to influence the future direction of the product in ways that I cannot even predict at this time.  The TFS team were always very good at listening to our feedback from a cross-platform point of view – but now we’re all part of the same team we’re even harder to forget :-)

But more on all this soon.  I’ve been so busy helping get Team Explorer Everywhere 2010 shipped along-side the rest of the Visual Studio 2010 release that I’ve been neglecting my blogging and podcasting duties.  But it’s great to be back!

However, in the past we used “Teamprise” to mean different things.  For example we have “Teamprise” views in Eclipse.  When you whent to import a project from Team Foundation Server you selected “Teamprise”.  Sometimes we used Teamprise as a product name, sometimes as a metaphor for accessing TFS. Sometimes we used it under the covers as well – for example as the name of an annotation in version control when storing check-in polices or as the layout type when doing work item forms. 

This was a deliberate decision at Teamprise.  When we started we were just a plucky start-up convinced that we were one of many working to put TFS into Eclipse.  We wanted to make our name synonymous with accessing TFS from Eclipse so that people would think of us instead of a competitor.  But we also wanted to allow competing products to exist in the same Eclipse installation so that users had choice as to which TFS connector they used and it wasn’t too confusing for them.  Largely this was a success.  We got a solution to market at the right time and managed to keep improving the technology and a competing product never really appeared.  To people who know Team Foundation Server, Teamprise == TFS in Eclipse and Teamprise == TFS cross-platform.

But, there was a whole world of people that we didn’t reach.  People would always need to know to ask “How do I connect to TFS from Eclipse, or How do I connect to TFS from the Mac” and be given the answer of Teamprise (either by a person or a search engine).

Now that we are part of the Team Foundation Server team, it doesn’t make sense to be as “visible” anymore as a brand in the UI.  When you are connecting to Team Foundation Server in Eclipse or want to see Team Foundation Server resources – you should look for Team Foundation Server.  When looking for how to connect to TFS from Eclipse, you should look for the product that contains a “Team Foundation Server plug-in for Eclipse”.  It is now Team Foundation Server we want you to connect with (both literally, and from a branding perspective).  All this means that it is more complicated than just doing a search/replace in the UI as now we need to figure out when we were using Teamprise to talk about TFS and when we were using it to talk about the software that you plug-in to Eclipse.

And then there was package renaming.  All of our code used to be in com.teamprise packages.  Some classes were called things like “TeampriseLogConfiguration” etc etc.  In each case decisions had to be made on individual merit rather than being able to come up with a simple automated cookie cutter approach.

The following is what we ended up with:

• In the UI, when talking about connecting to Team Foundation Server use that name and the TFS icon.
• Packages moved from com.teamprise.* to com.microsoft.tfs.*.
• Class names sometimes went from Teamprise* to TFS* or TEE* depending on use, or got a different name entirely.
• Eclipse plug-ins moved from com.teamprise.* to com.microsoft.tfs.*.   We also took the chance to do some refactoring here to make the plug-in names more sensible now that the codebase is much more mature and the roles and responsibilities of each plug-in is better defined than it was back at V1.0 of Teamprise when some of them were originally created.
• Extension points moved from com.teamprise.* to the appropriate plug-in com.microsoft.tfs.* based name.  This is important if you were previously using the Teamprise extension points to add integration into our plug-in from yours.  I’ve spoken to the customers and partners that I knew of that were doing this – however I expect more will want to once we make the initial Microsoft release and so we wanted to get the naming right now.
• Check-in policies keep their Teamprise based annotation names in version control.  This fact is totally transparent to end users, but means that we retain backwards compatibility with older Teamprise client defined check-in policies.  It also means that partners like JetBrains who have their own check-in policy implementation in the IntelliJ IDE that uses the “Teamprise” scoped mechanism for check-in policy storage need not change their code.
• The .tpattributes file lives on as the file that is used to store unix execute bit permissions etc, the .tpignore file lives on as the file you can use to specify resources that Eclipse should ignore.  Again this was for backwards compatibility.  We could have gone down a route where we searched for “.tfsignore” first etc but we’re hoping to be able to reduce the need for these files at some point in the future by making use of the new properties capabilities in TFS 2010 so we decided to leave alone.
• In the work item layout target names, “Teamprise” used to be the name of a layout target that was for the Teamprise client.  “Teamprise” is still accepted (for back-compat) but a layout with the target name “JavaSWT” now takes preference.  Therefore when we are looking for a layout target in Eclipse we look for one called:
  
1. “JavaSWT”, followed by
2. “Teamprise” followed by
3. “WinForms”, followed by
4. the last unspecified layout. 

If all this talk of layouts doesn’t mean anything to you then do not worry.  Neno has a good post here where he talks about using separate layouts for Web Access and Visual Studio where you will get the idea.

Hope that makes sense, we will have a beta out soon where you can take a look for yourself.  The moral of this story is that if you have to re-brand your codebase due to acquisition then be prepared that it will take more thought and effort than you might have originally estimated.

We are now after one more person to join our little family. We need someone to help us with our User Education work.  If you know of a technical writer that might be interested in working with us then please send them over to this job posting at Microsoft Careers (https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=2&jid=10007&jlang=EN). This role is based in Raleigh, North Carolina, USA

I promise you, it is a very exciting time to be joining our team.  I am looking forward to showing you a bit more of what we have been working on soon!