Will TFS 2010 Beta 1 upgrade to the final product?
I understand that there will be some issues, maybe a re-install even, but how does it compare to the installation drama that TFS 2008 had?
TFS 2010 Beta 1 is an early beta designed for standalone use when testing out the product. You shouldn't use it to run a production project and upgrading the Beta 1 server to later beta's or the final release is not supported by Microsoft.
This is the same as what happened with the early beta's of TFS 2005 and TFS 2008. When Microsoft offers a beta of TFS with a "go-live" license, that is usually the signal that an upgrade path of sorts will be provided from the beta to the released product.
Regarding the installation experience, having played with TFS 2010 for a while now, it is clear that Microsoft have spent a significant amount of effort on the installation and it is a lot smoother and more flexible than in previous releases. That said, you still need to ensure that you have your pre-requisites (i.e. IIS and SQL Server 2008) installed in the correct way. As ever with TFS, be sure to follow the install guide carefully.
Personally, I'd recommend testing out TFS 2010 Beta 1 in a Virtual Machine for now. You probably also want to install the client side Visual Studio Team Suite in virtual machines unless you are prepared to rebuild the machine that you install Beta 1 onto.
Brian Harry indicated that moving from Beta 1 to Beta 2 will likely have some hicups:
http://blogs.msdn.com/bharry/archive/2009/05/18/vs-vsts-2010-and-net-4-0-beta-1-is-available.aspx
If going from Beta 1 to Beta 2 will be difficult then going from Beta 1 to Release will probably have problems too.
I am betting it will have better support that a CTP does, but MS Betas frequently have "Upgrade Blues".
I would recommend installing on a temporary Virtual Machine for now.
I would guess that there won't be a seamless upgrade process. There wasn't during the VS2008 release cycle, and there isn't for the Win7 cycle (I know they're two separate divisions, I'm just pointing out that large public pre-releases from Microsoft don't seem to have good seamless upgrade experiences).
All beta release does upgrade the Final Product, otherwise they would have called final release :)
Related
I'm not asking a technical question, but a request for advice.
Over time, I have always used installshield as the primary tool in installer development, and this tool has always been the king of them.
Lately, everything has gone to the web and Windows Forms have lost their charm. However, these still exist, and there are needs about them.
But you don't see anyone talking about the latest technologies about Windows Forms, installers...
Do you think Installshield is still the main tool for build installers? Why isn't any extension available in the VSTS/TFS vNext market?
Even in Jenkins, the last time the plugin was updated ... was in 2014. And we remember that Microsoft used Installshield Limited edition for one Visual Studio Version, but dropped to bring back Visual Studio Installer.
I see there is a TFS template incorporating SDL (security development lifecycle) for 2013 (http://www.microsoft.com/en-us/download/details.aspx?id=42517) but it does not mention anything about TFS2012.
Does anyone know if it is compatible with TFS2012 or if there is an SDL template for 2012? (I don't want to install the 2013 version, only for it to break our TFS2012!)
I downloaded the MSI and took a quick look with Orca. From what I saw, the installer checks explicitly for TFS 2013 and and install an additional Web Service, that, I suppose interacts server-side and, therefore, is version specific.
So your only chance is to upgrade, which, from my experience is not that hard, if you do your homework.
I'm considering using VS2012 RC to put together coded UI tests (since VS2010 SP2 FP2 does not fully support IE9).
Currently, my test projects are contained within a solution which is connected to our TFS team project. I also set up a build definition to build the project when new code is checked in (the builds are performed on our build machine).
I suppose that if I upgrade my solution to VS2012, then to be able to build the solution on the build machine I will need VS2012 RC installed there too, right? But then is it possible to specify in my build definition for my project to be built by VS2012 instead of VS2010?
Is it possible for me to upgrade my project with VS2012 while still using TFS2010? I should note my solution will be the only one upgraded to VS2012. All the other solutions in the company still need to be built by VS2010. A company-wide upgrade to VS2012 won't be in place for at least a few months, I imagine.
Or do I need a separate build machine or anything?
Any thoughts, ideas or solutions appreciated!
UPDATE: So I gave it a try, and everything worked okay. My only problem is that the Coded UI tests I have didn't work after being re-built on on my build machine, but I suppose that's probably something I'd need to ask about elsewhere. To clarify, the solution built successfully, but the tests still failed.
Visual Studio 2012's project changes allow most types to still be opened by Visual Studio 2010 with SP1, so it depends on what kind of projects are in your solution - see this page for the full compatibility list:
If you created your assets in Visual Studio 2010 with Service Pack 1
(SP1), many of them will load and run in Visual Studio 2012 without
any further action on your part. Many assets will also open again in
Visual Studio 2010 with SP1 without any issues, even after you open
those assets in Visual Studio 2012.
See also "Round-tripping with Visual Studio 11" on the VS blog which has more detail.
Note though that if your build process uses custom build activities then just installing Visual Studio 2012 breaks the build definition on your local machine, and also that MVC1 or MVC2 projects just aren't supported by VS2012. Oh, and Visual Studio 2012 isn't a RC any more, it was RTM'd last week.
(I presume you mean 2012 RTM rather than RC, now that the final release is available)
Theoretically (from what I've read) VS2012 and VS2010 use the same project/solution file format, so you should be able to switch between them without any compatibility issues (aside, presumably from obvious things like creating new file types that VS2010 doesn't understand)
TFS updates have historically been backwards compatible, so you can usually use different client and server versions (but usually you need a compatibility pack installed for old clients on new servers, a new client running against an old server has usualyl been fine). So I'd expect this to work well.
I'd say try it, but diff any files that appear in VCS2012's Pending Changes carefully before you check in to be sure that it hasn't changed anything that will cause problems. The worst that can happen then is that your development machine gets a "corrupt" version of the code and you'll need to revert to 2010.
(This is the approach I've been using with our 130-project C# solution, and so far (1 day) it's working fine, apart from the new UI making my eyes bleed as they try to find the information in all the indistinguishable monochrome clutter)
we are developing white label web and mobile healthcare application for our clients. our product is evolving rapidly and we are supporting existing clients and going to support new clients.
current development workflow involves SVN for source code, requirement documents tracking and mantis for defect tracking.
We are considering VS TFS 2010 based Application life cycle management for our organization. we are hoping that VS TFS 2010 will help us streamline the following
1) Requirements Management
2) Source code Version control
3) Build automation
4) Test management
just wondering is anybody have experience using VS TFS 2010 and would like to share their experiences? is there any worthwhile alternatives to VS TeamSystem?
Preface: This is a personal opinion and I have no ties to Microsoft other than that I develop with their tools for their platform, even though I come across as a Microsoft lover in this answer. (which I am - I love .NET development)
I haven't used TFS 2010, but I HAVE used the 2005 Team Suite including TFS and the Visual Studio versions supported. We didn't move forward to 2008 or 1020 because of how extraordinarily difficult the 2005 version was to install. However, once we got it installed... Loved it. The project management tools were intuitive, and worked well. Setting up builds was a breeze, and it did everything I wanted it to do simply and efficiently.
Since then, however, we've adopted open source tools to do the same type of stuff. As I said, the install of 2005 was a NIGHTMARE and even though the 2010 version of Team Foundation Server installs VERY easily (I tested it myself and demonstrated it to the poor team who helped with the 2005 version just to show them how much better it is), I was unable to convince my team to give it a second chance. They chose to stick with tools that didn't need to be upgraded as often, and that were easier to upgrade when it did need to be done.
If it were just me, I'd be using it. This is one of those things where things just work right, and work together seamlessly. And the available documentation (MSDN, videos, etc) is exhaustive. I doubt any other set of tools is as well-documented.
It's just too bad that the experience with the older version was so bad that nobody else here will give the newer version a fair shake.
As for alternatives - it's not open source, but Atlassian has a nice set of tools. They work well for Java and we're using some of them in our .NET shop. We're using SVN for source control. That's about the only thing I like better about our new environment than I did the Team System.
I started at a new company 2 months back that uses TFS 2010 exclusively (for source control and issue/task tracking), and I haven't been able to get comfortable with it. Previously, I've mainly used SVN for source control and either OnTime (by Axosoft) or Fogbugz (Joel Spolsky) and have loved them both.
I don't know if it's the way they're using TFS (branching is nothing as nice as it was in SVN... and they have Product Backlog Items, Sprint Backlog Items, Bugs, Impediments, and god knows what else to keep track of) but I find it way too convoluted.
I think the tools a developer uses should assist the dev, not get in the way of. If I have to stop and think about how to branch code or assign an issue, then something's wrong with my tools (or I just need to spend more time learning them... which doesn't make sense to me either).
We have a ton of code written in Dexterity, whose only Source Control integration option is SourceSafe. Are there any products out there that could act as a bridge so that Dexterity would believe it was talking to a SourceSafe server, but all the commands were actually translated to TFS (2010) actions?
Yes - that's exactly what the TFS MSSCCI Provider (2010 Beta 2 version) does.
Dexterity doesn't appear in the list of supported apps so it's probably not very well tested, if at all. On the bright side, Michal is very receptive to bug reports; hopefully he'd be able to fix any issues you encounter before the final 2010 power tools are released.