I have a field defined in TFS so that it maps to the Finish date in MS Project. When I load the data from TFS into MS Project that field does not populate into the Finish field. However, when I populate the Finish field in MS Project and click on Publish it DOES update the field in TFS with the added/changed date.
What am I doing wrong? I mapped my ETA field to the Finished field, but when updated it only goes from Project to TFS. When I add an ETA date to something in TFS it will not populate in Project when I try to open the work item from TFS to Project.
Let me know if that doesn't make sense or if you need further clarification.
Thank you,
Shanna
This behavior is expected if the full field name you use is not the one from Microsoft.
To be clearer, if you created the field yourself with a full name you came up with: it won't be used by MS Project.
You have to just the Microsoft's field, in this case: Microsoft.VSTS.Scheduling.FinishDate for MS Project to pull the data from the Work Items when loading the MS Project sheet.
Note that you can set the relationship from WIT Field and MS Project field manually in the Team Project definition. Use the Process Template Editor (from the TFS Power tools) to do so.
More info about the Scheduling fields here
Related
My team currently works with an on-premises TFS 2012 server. I am migrating everything to Visual Studio Team Services, formerly Visual Studio Online. I am starting with a test project and was able to easily get all the code migrated, but can't figure out how to do the same for the work items.
Are there any good guides out there?
New options as of March 29th 2018:
TFS to VSTS migration - The official import option which will import 1 project collection into 1 VSTS account. It automatically imports everything stored in the backup. At the point of writing this, the TFS must be upgraded to TFS 2018 and some work item template customizations must be removed (there are a few well documented features unavailable on VSTS).
VSTS Sync Migrator - Marting Hinshelwood, the uncrowned king of TFS and VSTS migrations, has built his own little tool that can migrate work items from one server/account to another. It can even do migrations from one Team Project to another and while doing it switch between process templates.
VSTS Work Item Migrator - Microsoft has also open sourced a project that they used internally to migrate work items. It's less powerful, but it was made by Microsoft.
Previous answer:
At the moment there isn't a really good story. Your options are:
Start over - easiest :).
Start over and manually recreate items of value - It's a pain, but it's some teams have done these things in the past. keep the old TFS server available in read-only mode and each time you use a work item in the old system, you manually create it in the new one, set all the fields and upload the attachments. Depending on the number of items it'll take you a few sprints to migrate the most important stuff over.
Wait a while longer - Microsoft is currently working on a full fidelity import option which will allow you to upload a Project Collection and it will be exposed as a new VSTS Account (it's not going to be possible to import a project collection into an existing account).
Use Excel for import/export - Will work for most work items, you loose attachments and work item links other than parent/child. The trick is to extract from one Project Collection then copy all fields, except the ID to an Excel sheet bound to the target project collection. You will need to fix all Identity fields (works best when users have the exact same display name on premise as in VSTS) and you'll have to import once with state new and then past the current state/reason over the just imported values and sync again. Test Cases, Plans, Suites and Shared Steps will not be imported with their relations in tact. The approach would be very similar to this one.
Use the TFS Integration Tools - Will work for most work item types, though it will loose custom kanban states and tags. Test cases, Shared steps and their relations will not be imported. This option will allow you to import import work items and source code with their relationships in tact.
Use a 3rd party solution - Out of the available options currently OpsHub offers the most complete solution. For test case and source control link migration you're looking at the commercial edition, which comes at a steep price. It still has a long list of known issues and last time I tried it, I ran into numerous issues which required their support to resolve them.
There are specialized TFS consultants who live off these kinds of migrations if your current state of the work items is precious to you, then you could reach out to them.
See also:
https://www.visualstudio.com/en-us/articles/adopting-vsts
This is my first attempt at writing a Visual Basic app using Visual Studio. I am using an Access 2013 database as the source and everything was going fine until I decided to add some calculated fields to one of the tables. Now VS is telling me that I need the "Microsoft Office 14.0 Access Database Engine OLE DB Provider" to read the tables.
I've been searching and searching but can't find anything about version 14.0 of the engine. Am I just missing something simple, or can I not access calculated fields in the DB and have to just pull the data and do the calculations in the app?
I am working on a machine with Win7 64bit, Office 2013 Pro, and Visual Studio 2015 Community.
Thanks!
EDIT: The calculated fields look like this:
"http://travellermap.com/api/jumpmap?sector="+Left([Sector],4)+"&hex="+[Hex]+"&style=print&jump=3"
Where [Sector] and [Hex] are fields in the same database. As soon as I added the fields to the database VS2015 would throw the error. If I tired use the Dataset Wizard it would tell me that there were fields in the database that were missing or could not be read without v14 of the engine.
Then even after I removed the calculated fields it still could not read the data. I have to revert to a backup copy of the database that never had calculated fields in it to get things back to working.
My exact steps were as follows:
Create database with multiple tables
Create a view that pulls together data from all the tables that I needed.
Create dataset in VS that uses that view which I called SystemMaster
Build app around it using the XAML designer
Decide that it would be quicker to use a calculated field int he DB than write the VB code to put together a URL that is needed to display an image in the app.
Close out VS2015 and laucnh Access 2013
Create the calculated field in the primary table and edit the SQL code for the view to include those fields
Save and close Access, go back into VS2015
View the dataset to see if the new fields are there, see that they are not and launch the Wizard only to find out that the Wizard says it can't access anything in that view anymore because fields are either missing or can't be read with the current version of the Access engine (12.0) and that I need version 14.0.
Search for answer, don't find one. Remove the fields from the tables and try to get back to a working application.
Realize that even after removing the fields, VS2015 won't read the tables ro views that had them.
Revert to a version of the database that did not have the calculated views, and everything works again.
While I know that the proper way to do this would be to construct the URLs in the VB code, this was easier and quicker (in theory) to do at this point which is basically a proof-of-concept/prototype.
I want to express dependencies with links. A is dependent on B. I would like to be able to express that A needs B by some Date. Is there a way to annotate the link with a date?
Although it is valuable to understand your dependencies, especially if you have more than 2 teams working together on the same product you can't add dates to the link.
You can however add the rate to the feature or epic that are related. At this time there is no delivery date or required by date in VSO Associated with a PBI or a bug. Customisation of work items is due in the near future on VSO so that you can add that field.
Can I somehow get a build number into an extended property of my published database?
I use SSDT Projects and tfs build.
I want to get as much information as possible into the database.
I know there are a few variables, such as database name. Perhaps there are more?
Even build date would be useful (timestamp from when the deployment script was created).
But ":setvar ts GETDATE()" won't work since the GETDATE not being evaluated.
EDIT: I got it working by editing the xaml and then using XmlPoke. I can post more details if there is interest.
Pass the build number to a post-deployment script that is updating the extended property
My company are working at Sharepoint site that we are developing using Visual Studio. The actual installation at the customer is performed by scripts deploying the produced wsp-files. During normal development I mostly use deployment from directly from inside Visual Studio. Unfortunately I often run into problems when trying to deploy my solutions. We are using a server-farm set up, but each developer has their own virtual server, datebase instance and so on.
We have one project file that the define the basic content-type used for different department. This content-type typically define stuff like what period that the list item cover. Each department have their own project that uses the content type combined with department specific fields to form the final list.
One of my current problems is that when I make edits to the content type and deploy it the changes does not seem to propagate. Even though I rebuild the solution and deploy both the base project and the department project with success I still see the old version of the content fields when I create a new department list. Sometimes it helps to retract the projects, but often I literally have to restart everything before it works.
My question is if this problem is caused by Visual Studio not really deploying my new defintions or if there is some architectual aspect of Sharepoint 2010 that might prevent the change to propagate. What steps can I take to lessen the likelihood of the problem occuring?
Have you tried deleting the content type with Central Administration before doing a new deployment? I've found out that Sharepoint don't update/create content types when it finds other one with the same name.