We're running a German TFS 2013.4 on premise and want to move to Visual Studio Online. The OpsHub migration tool stops with a template mismatch.
I ran the TeamProjectManager tool (https://teamprojectmanager.codeplex.com/) and compared our template to the VSO template. The fields are there, but their names are different, one is German and one is English ("Fehler" vs "bug").
Would it be possible to convert our local TFS to English? It's a single-machine installation running in a VM, so we can take a snapshot and just try it. We don't have any customizations, but TFS was upgraded several times, all the way back from TFS 2008. I read somewhere that might leave behind some obsolete fields, which can also cause problems.
I'm not certain, but I believe you would still have to rename your Work Item types even if you changed your server to English.
Do you need the history in VSO? Would it suffice to export TFS Work Items to Excel, map the fields and import to VSO? Obviously version control history would not be carried over either but you would still have the on-premise archive.
The TFS Integration Tools would likely do the job but they are NOT fun to use.
https://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe
*Sorry, this would have been a comment rather than an answer but SO wouldn't let me add one.
Related
I've created an Outlook add-in, debugged and works fine. I want to be able to package it up for distribution. This is for a very limited audience 5-10 people. What are the steps to doing so?
I tried Build | Publish which appears to work (using options of local filename and CDROM install location), but creates a massive 1.5MB setup.exe file and when it is executed, takes forever (it appears trying to contact some remote server and times out and pops an error, although the add-in appears to be registered).
Looking online, I found references to creating a SetupProject or using InstallShield Limited addition, but none of those appear to apply to Visual Studio 2017.
I'd be happy if I could just provide my DLL and a .reg file -- this is for a small set of 5-10 power users.
What is the simplest way to deploy this add-in?
The easiest way is Build | Publish. Just disable any online activities if you don't want it. You can do that in Project -> Settings -> Publish. Check your "Updates" settings for example.
You can download a Visual Studio project type from here:
https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects
This will allow you to deploy the package, but it's somewhat buggy in my opinion. Also, the link above does not have any documentation. You have to go to another page for that and the answer is buried in the comments:
https://msdn.microsoft.com/en-us/library/ybshs20f(v=vs.90).aspx
The ClickOnce has worked more consistently for us, however. Just right-click and select Publish on the Project.
It is a long ways off from the old InstallShield LE process, which allowed you to customize the entire process including images, click-through licensing, etc.
But the InstallShield LE had it's own set of issues, and seems to have been all but abandoned.
It may be worth looking at other 3rd-party tools like WiX (http://wixtoolset.org/) to get things installed correctly, or even manually writing your own installer to get things put where they need to be.
I've installed the OpsHub VSO Migration Utilty and I'm trying to migrate one of our smallest projects as a test.
Having created a new matching project in VSO the migration validation fails on the template mis-match.
The existing TFS 2010 project is based on the MSF for Agile Software Development v5.0 template and the new VSO project is MSF for Agile Software Development 2013.3
As far as I'm aware, neither of these templates have been customised.
For each work item types the mismatched fields are:
RelatedLinkCount
AreaID
AttachedFileCount
HyperLinkCount
ExternalLinkCount
IterationID
Installed version of the utility is v1.1.0.005
Any help would be gratefully received.
Between TFS 2005/2008 to TFS 2010, the process templates were updated to add an additional space in the display name of each of the fields you mentioned. Since that's the case, you can take some easy steps for a workaround and then re-run the OpsHub Visual Studio Online Migration Utility.
You'll want to use the witadmin.exe tool and specifically the changefield option. Here are the steps you'll want to take to change the display names of each of the fields to include the spaces:
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.RelatedLinkCount /name:"Related Link Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.AreaId /name:"Area ID"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.AttachedFileCount /name:"Attached File Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.HyperLinkCount /name:"Hyperlink Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.ExternalLinkCount /name:"External Link Count"
witadmin.exe changefield /collection:http://tfs.contoso.local:8080/tfs/DefaultCollection /n:System.IterationId /name:"Iteration ID"
Give those a try and I hope it works out for you as a workaround!
OpsHub unfortunately need to fix this, or you can use a different tool.
When you try to do a migration the OpsHub tool compares your Process Template between the two projects and throws its toys out of the pram if they are not the same. In your case your 2010 server once was either 2005 or 2008. In TFS versions prior to 2010 the fields that are conflicting did not have spaces, from 2010 on they do... Hence the mismatch.
There are other, less nanny state, ways to migrate but they are much more complex.
TFS Integration Tools - this tool is free, supported by Microsoft, but is increadably complex. It was built for consultants working with enterprises to move TFS data around. Not fun, but can be made to work.
Excel migration - you can just use excel to move the tip of work items and move the tip of TFVC source. Or move to Git in VSO and use Git-TFS to move with history for source.
Hire someone (admission / ALM Consultant talking) - Most of the ALM MVP's are consultants and have tools to move your stuff.
I would suggest that #1 and #3 are of similar cost at the end of the day, and #2 tends to be unpopular.
Check out the migration guidance from the ALM Rangers.
Because that is exactly our scenario (TFS2008 > TFS2010 > VSO) and we also got the error during migration of work items with OVSMU from TFS2010 to VSO I was willing to give the workaround described by Ed a try.
To have it more convenient I tried not from command line but with Visual Studio 2012 from the menu Tools: Process Editor: Work Item Types: Open WIT from Server.
First try was work item type Task. After change of all relevant names I was asked if I wanted to save changes to the item. After pressing Yes I have got the message window:
"Microsoft Visual Studio: Work Item Type: Task
TF26177: The field System.IterationId cannot be renamed from 'IterationID' to 'Iteration ID'.
There were validation errors. Continuing to save may cause the file to become unloadable, do you want to continue?"
Do you have some additional advice for me to bring it all to the point where I can migrate the work items?
I have a small team of web developers who work together on up to 50 external sites. I am trying to find a better solution to using Dreamweaver's check-in check-out for managing source. We have just started using Visual Studio 2012 here and there and I am curious if TFS is the way to go for us. No one here has ever used versioning or any type of source control before, so I am looking for something similar to what they are used to.
If it matters at all, our sites are all hosted on a Windows 2008 R2 server, and largely written in C#.
I think TFS is a good option to consider. As several people have commented, it will be a jump from what you are your team are used to in Dreamweaver, but I personally feel if you are serious about managing your intellectual property, you will invest in some sort of version control system. With that said, there will be a learning curve regardless whether you are your team select TFS, SVN, Git, etc.
Assuming you do go with TFS, you do get the added benefit of everything else that comes with TFS - it's not just about version control. This includes work item tracking, automated builds/deployments, reports, a simple SharePoint site, etc.
With TFS you get the benefit of all of these features, combined into a single product. You can accomplish a similar setup using open source products as well, but would require you to piece the products together.
I'd use the integrated Subversion client in Dreamweaver, which does the basic stuff very nicely and doesn't require the tedious navigation process that will lead to your team bypassing the system. Only problem, DW does not support the latest versions of SVN so you need to pick up an SVN server that is compatible. Try this:
Setting Up Version Control for Dreamweaver CS6 on Windows
Any previous attempts to get version control working may well have created some .svn folders and files on your PC. You MUST remove ALL of these and UNINSTALL ALL OTHER VARIETIES of Subversion software from your PC before you start.
Go to the VisualSVN Server website and download an archived standard version of their software, version 2.1.16 . Don’t be tempted to grab a later version, because this will install SVN 1.7 or 1.8 and neither will work with Dreamweaver.
http://www.visualsvn.com/server/changes/
Trying to get DW working direct to a local folder using the file:// protocol probably won’t work and is also known to put data at risk. You need the server. I chose to install the VisualSVN server with the default settings, other than opting to use Windows logins and go with HTTP, not HTTPS. I decided to have the repositories live on an internal SSD drive, but any local drive will do. When creating a folder for your repositories to live in, use a name that is pretty general e.g. ourcorepositories . I used lower case for everything.
Right click on ‘Repositories’ to create a new one. Give it a name without any spaces or special characters e.g. mynewprojectrepo and check to ‘Create default structure’ . Before you OK, note the Repository URL and copy it into Notepad or a similar plain text editor so you can refer to it later during 6 below. It will be something like
http://OFFICEDESKTOP/svn/mynewprojectrepo
Notice that the capitalised part of the URL is the name of your computer. Click OK and you now have a repository for your project.
5. Boot DW and go to your project. If you don’t have a project yet, create one and stick some dummy files and folders in it. Go to Site menu>>Manage sites… and 2-click your project. Select Version Control.
6. Set Access to be ‘Subversion’ (no other choices exist), Protocol to be HTTP and for the Server Address enter the name of your computer in lower case e.g.
officedesktop
For the Repository Path enter (e.g., using current example from 4. Above)
/svn/mynewprojectrepo
The Server Port should be 80 . For the Username enter your Windows user name, in lower case. Enter your Windows password for the Password. This is the name and password combo that you use to log in to your PC . Click the Test button and you should get a success message. If not, the best advice is to delete any .svn files and repositories you have created and start again. Be sure not to add any slashes or omit any; the above works. Before you click Save, click the link to the Adobe Subversion resources and bookmark it in your browser. There is a lot of useful background information there. Click Save, click Done.
7. Go to your DW project and open up Local View. All of your site’s files and folders will have a green + sign beside the icon. Right-click on the site folder and click ‘Version control>>Commit” . It is a very good idea to leave comments whenever you change anything, so leave a Commit Message along the lines of “The initial commit for My New Project” and click to Commit. If you have a lot of files to go to the repository, they’ll take some time to upload. As they upload, the green + signs disappear to show that you local version is in synch with the repo.
8. Okay, that’s it, you have Version Control in Dreamweaver CS6. It may also work in CS5 and 5.5. Check out those Adobe resources for some good insights on workflow. I can’t help with any other ways to implement version control, but I can maybe save you time by saying that DW doesn’t integrate with Git and that the basic, but integrated, Subversion client in Dreamweaver is way better than having no version control. For coverage against physical disaster, I’d also add in a scheduled daily backup of your entire repositories folder to some cloud storage.
Apologies for any errors. I’d recheck all of the steps, but A) I think they’ll get you up and running and B) it’s easier to do the install and set up the first time than the second time (all those .svn files and folders to get rid of).
Environment: Visual Studio 2005, SSRS 2005 with Sharepoint 2007 integration
Have a project with two reports and one data source. Has already been deployed to production sharepoint farm.
Needs an enhancement. Change properties to point to test farm and try to deploy:
"Access to the path 'c:\documents and settings\\my documents....\RegLog.rds' is denied"
Path is correct, and properties of files are read-only (because the files are checked in to source control). Now, I understand that SSIS packages won't execute if they are read-only (which is stupid) but I am fairly certain I have deployed SSRS reports and data sources before without having to check them out first. On the other hand, I do know that deployment requires the file to be modified in some way. But the modified version will be in Sharepoint, not in visual studio, and its extension will be .rsds, not .rds (which is the VS name)
I also think it is unusual that the path has been lower-cased. Shouldn't matter in Windows, but it's the first time I have ever seen "documents and settings\\my documents" not all initial caps. So maybe it matters. But this project deployed before without problem.
I was having this problem as well. To fix it, I did a build of the report project (which before converting from 2005 to 2008 I'd never had to do before). Once I did that, it worked just fine.
I have a smallish utility library I made that I had created in TFS Beta 2 to test out TFS. I now have TFS rc1 installed(and Beta 2 uninstalled) and am trying to add my Solution to TFS.
I get an error saying that it is already bound to my old TFS, which was on a different system then this one. Strangely, when I go into Source Control and look at the bindings it says there aren't any. Also, I manually deleted the .vss and .vsc files and it still does it.
Ideas? I looked through the numerous other SO topics related to this but unless I missed one none of them are dealing with my issue.
Ideas?
Grab the TFS Sidekicks from Attrice. They have a workspace sidekick, you can pretty quickly find your old machine and unbind/delete that workspace from TFS.
Once you install:
VS Menu Bar
Tools
Team Foundation Sidekicks
Workspace Sidekick
Owner will defult to you, just clear machine name
Search
Select old workspace, click the red X to delete
I had old server entries too and I fixed it by using the workspace sidekick mentioned here and then using the command line to get the rest that the tool couldn't find.