TFS 2005 to 2010 - Custom Work Items - tfs-workitem

just a quick question.
If we migrate from TFS 2005 to TFS 2010, what happens to any customized work item we developed on 2005? Do we have to recustomize, or can they be imported/carried over into 2010?
Thanks in advance,

By default, nothing will change for existing Team Projects, which means you won't benefit of the improvements made in TFS 2010 (e.g. versionned typed links).
If you want to benefit of these new features you'll have to introduce them manually by editing the definition of your Work Item types.
There are no real tool or process to migrate existing Team Projects created with TFS2005/2008 to TFS 2010, mainly because each case is different in the way you want to handle it.
My advice is to create a sandbox team project using the WIT definition of your customized Work Items, then make some tests of improvements with TFS 2010. When everything is ok and stable then apply the new definition on the existing Team Projects you want.
Of course new Team Project created with the new Process Template will be the way you expect.

You can find the steps to enable the new features at http://blogs.msdn.com/b/allclark/archive/2009/10/13/enabling-new-application-lifecycle-management-features-for-visual-studio-2010-beta-2-in-upgraded-team-projects.aspx
For TFS2012 we have added a wizard that configures the new features in your team project automatically, but that only works if the TFS2010 features are correctly configured.

Related

How to create an Empty web project (no C#, no MVC, no .Net References) in Visual Studio 2017

I need a web project that can be deployed to a web server (in this case IIS), however I do not want anything other than static HTML, TEXT and JSON files in the project. I don't want to do a build. I don't want a Properties folder. I don't want a BIN folder. I don't want an OBJ folder. I don't want any NUGET packages. Most of all, I don't want any DLL or .Net references.
I have tried the solution proposed by Microsoft here: https://social.msdn.microsoft.com/Forums/vstudio/en-US/7589fbbf-732d-4c99-b9e9-7fe247f18f5a/how-to-create-static-web-site?forum=visualstudiogeneral
This is not even close to a static site.
And, here: https://marketplace.visualstudio.com/items?itemName=MadsKristensen.ASPNETCoreTemplatePack20173 I found an updated template which says it will create a static site without C#. It does not. Roslyn is included as is .Net CORE. Also at least 1 C# file is still generated and is still needed.
I tried going back to Visual Studio 2015 to see if there was an option there, which I could then just reopen in VS 2017, but I found none there either.
Anyone know how to create a truly empty web project for VS 2017, which can be published, but has only static content?
The solution suggested, that of using a Blank solution, really does not offer a solution at all. The blank solution still has no projects, and adding a project pulls in all the ASP.NET and/or MVC pieces I am trying to ignore.
I did find that I can use 'File->Open Website', browse to a folder with the static content and open the web site in Visual Studio. Once I have altered the content as desired, I have to use 'Website->Copy Web Site' to copy the files to the IIS server. A packaged deployment is not available. The 'Copy Web Site' indicate which files have changed so it is pretty easy to figure out what files need to be updated. To copy one or more files, use the connection buttons at the top of the dialog, then select files as necessary on the left and use the arrows in the middle of the dialog to move/copy files to the IIS server on the right.
Image of Copy Dialog
The result is a project I can open and edit in Visual Studio, which can be easily deployed/updated from inside Visual Studio. I tried the solution in VS 2015 and VS 2017.

What is the easiest way to get TFS 2013 to run unit tests via VS 2015

We have Team Foundation Server 2013 installed with Visual Studio Professional 2015 and I've been able to get continuous integration builds working using the TfvcTemplate.12.xaml build process template and the "/tv:14.0" MSBuild argument. However, I can't seem to find a way to tell TFS to use the 2015 Unit Test suite.
This post Build VS 2015 Solution w/ Unit Tests on TFS 2013 Team Build worked around the problem by installing VS 2013 on the build server, but that means that the build server would use the 2013 testing framework rather than the version used by the developer.
Another option is to use an older build process template that uses MSTest, which supports the "ToolPath" parameter, but MSTest appears to be deprecated (MSTest V2). BTW, I tried using the MSTest V2 NuGet packages, but that didn't have any effect on the framework used by TFS, which made sense once I thought about it.
I assume that there should be some way to tie in a third-party testing framework, but the examples I've found use the older build process template.
Has anyone else found a solution for this?
If you need your test agent or test controller to work with TFS 2013,
use Agents for Microsoft Visual Studio 2013 Update 5 and
configure the test controller.
Source Link: Install and configure test agents
This is the official recommended practices, we don't suggest you to use some third-party testing framework for handling your situation (not sure if there were).
Besides just as MrHinsh commented, we encourage you to move to new web-based build system which is more excellent. For the detail benefit of VNext builds, you could refer to this article Why You Should Switch to Build VNext

How do i specify Visual Studio test runner in tfs build script

I have used Microsoft shims in my project for writing unit tests. These tests run fine on my local machine, however when build on server the tests fail as the ms test runner does not support shims. After searching alot i found that i have to specify vs test runner to run test but it can be specified only in default template. Is there any way to specify the test runner in build script file.
I am using TFS 2013 on TFS server with upgrade template.
The Upgrade template was provided only for backward compatibility for folks that has serious customization investment in 2005/2008 builds. I would not expect new functionality to work in legacy builds without serious rework and effort.
I would suggest that there will likely be less effort in moving your build to the modern build templates and gain access to new features effortlessly.

Toolbox Disabled in Visual Studio Express

So I decided to learn some Win32 programming in C++ and thought i will try adding the controls from the toolbox and tada!! no tools there. Even if i try to choose the Com controls manually it still doesn't get shown. If i do Show All , i can see all the tools are disabled even the ones i selected.
I have seen and tried almost all of the solutions seen on the internet (reset toolbox, remove the tbd files, remove reg keys, fresh installation etc) to no avail.
I was using VS2012 Express initially but I have also tried a fresh installation of VC++ 2010 Express with the same result.
So I have two questions:
1) Are the tools not supposed to be there in an Express installation?
2) If they are supposed to be there could someone help me with fixing this issue?
This is by design. The Express editions don't support building GUI applications in C++. All of the controls in the toolbox require .NET. You'll need to create a new project of the appropriate type using C# or Visual Basic to use any of the controls.

64bit deployment

I would like to start making my application's 64bit, however, I am not sure on the changes I should make on my sln and vsproj files. What changes should I make to my sln and vsproj to make them 64bit?
On the same note, are there changes to the default sln or project file that are good for game development? I am using Visual Studio 2010.
From the VS menu select Build|Configuration Manager.
On the Configuration Manager dialog, open the Platform drop down and select <New...>.
On the New Project Platform dialog select x64 as your platform and click Ok.
To add to what was said before, make sure you understand why you need 64-bit support. In most cases you won't need access to larger memory allocations. Also, be aware that there will be x86/x64 P/Invoke compatibility problems (if you plan on using third-party unmanaged assemblies - in case you are working with managed C++).
For more information, read what Scott Hanselman has to say about this. Also, just as a sidenote, I would recommend reading this blog post that explains some of the migration ideas.
you need to add x64 solution platform:
Build -> Configuration Manager -> Active Solution Platform -> New -> New platform = x64
if you don't see "x64" make sure you installed it in Visual Studio installer
then just select "x64" as active solution platform and build