I was testing the msbuild and made a sqlproject and a deploy process template which I have to show working in order to actually buy tfs, but my TFS trial licence expired and since I work every time on a vm I've lost all local data.
How can I retrieve my project?
Microsoft allows you to obtain new trial ID's and extend your time.
Extending Trials of TFS 2010,TFS 2012 and beyond
Also if you have an MSDN subscription you can find a license key there. That and it's only around $500 to buy a license.
Related
How can one migrate from Visual Studio Online to an on-premises instance of TFS (version 2017)?
Ideally I'd like to migrate all code, project management data, etc.
Thank you for your time
There's no way to do this without the use of third-party tools, all of which will result in some amount of data loss.
There is currently no way to move from VS Team Services to Team
Foundation Server or to export a project or project collection in such
a way that it can be attached to a TFS server.
Depending on what features of VS Team Services you're using it may be
possible to migrate some of the data to a new target environment with
relative ease. And depending on what you're willing to lose you may be
able to migrate some other bits easily as well.
There are 3rd party tools that offer migration to and from VS Team
Services, though these can be pretty expensive.
Refer to this thread for details: Move from VS Team Service to an on-premises TFS
I do have two visual studio online accounts:
mypersonalaccount.visualstudio.com (free basic) and
mycompanyaccount.visualstudio.com (paid)
I started a small project into my personal one a few years ago. Now this project grows up and we create a little company.
I would like to change this project from my personal account to the my company account. in order to take advantage of the paid features.
How can I migrate a project from one account to another?
I would like to change the ownership for all data, no just the code repository but all tasks and sprints data too.
There is no such tool provided by Microsoft. Microsoft supports the migration from Team Foundation Server on premise to Visual Studio Team Services.
What I would suggest is to either use alternative tools like the vsts-sync-migration, or write your own PowerShell scripts leveraging the VSTS REST APIs to move the data you need.
I work from a small IT department and I'm pushing to move from our current TFS implementation to Visual Studio Online. My boss who gets the final say is hesitant because "What if Microsoft decides to stop offering the service, without notice, or their servers fail how will we get our code". While I find such a scenario unlikely and the scenario of our TFS server crashing and burning with no backups/bad backups much more likely. I still need to address his concern.
Does anyone know of a way to "backup" a remote TFS implementation? So far the only thing I've come up with is doing a nightly pull of Visual Studio Online and submitting it to a local repo, feels hacky, feels wrong.
Take a look over at the discussion on this StackOverflow question: Is There A Way To Backup Visual Studio Team Services Projects?
Here is Richard's answer:
There's no out of the box backup ability.
Now, if you are only referring to source control, and not work items,
pull requests, builds, test plans or anything else that the service
offers, then I'd suggest you migrate your code over to git.
With git every developer will have a complete copy of the source
repository, including all history and commit comments. From there,
it's a simple task to push the git repository to a different git
hoster (such as bitbucket or github) and make them your new centrally
hosted git repository.
On a historical note, Visual Studio Online at one point offered a data
export for a period of time. You might want to add a vote or three to
this related UserVoice idea to help raise the importance of the
feature with Microsoft.
Side comment: The business risks in using Visual Studio Online will
come from either Microsoft shutting down the Visual Studio Online
service or that the underlying Azure infrastructure has such a
catastrophic failure that your Visual Studio Online account is
unrecoverable. Both of those are extremely low risk, and very likely
lower than the risks you'd have running TFS on-premises, in your own
data centre, unless of course, your infrastructure and staff are
better than Microsoft's :-)
I agree with Richard. Visual Studio Online is not going anywhere :) You can also use tools like OpsHub, TaskTop, and Kovair to setup a two-way synchronization or use the TFS Integration Platform to do the same thing if you really wanted an option. If you are using Git repositories, you can clone the repository into other locations to maintain multiple copies. All of those options take effort.
I posted the same answer to this stackoverflow question.
We developed our own VSO backup tool. We scheduled it as a scheduled task and it runs once a night. It then
just clones all our repositories to disk.
Taken from this blog:
We use the VSO Rest API to query our VSO account and get all the data
we need. Since in VSO you can only have one Team Project Collection,
we retrieve all the team projects of the default collection. Each of
these team projects can have multiple repositories that need to be
backed up. A folder is created for each team project and saved to a
location on disk that can be configured in the app.config. When the
team project folder is created, the task loops over each repository in
the team project and creates folders for each repository.
You can also fork it on GitHub here
I'm working on a check in policy and while testing it the first time, I got an email from a teammate saying he couldn't commit any files, because when I installed the policy for testing on my machine, his TFS died, because he didn't have the policy DLL installed and registered. It seems that when I registered the policy locally, the TFS server registered it for the whole team, and the other members don't have it yet, so their commits blew up.
But how are you supposed to develop and test a policy if the only way to do this is installing in the global TFS server for everyone? Clearly, the policy code isn't ready for deployment before you ever try to test it, and you can't test it if testing breaks TFS for everyone until you test and deploy it.
What is the way out of this problem? Ideally, I'd like to have a local-only policy, but that doesn't seem to be possible.
Policies are set on a per Team Project basis. There is no local setting for check in policies, they are created against the Team Project and everyone who is using that Team Project will be affected, meaning that you will have to roll out the dll to all users.
Your best solution is to have a test Team Project where you can try out new builds / check-in policies and other bits and pieces in isolation.
Once you are happy with what you have, you can then apply the same items to the main Team Project that your team is working on.
We have a commercial software product and we are about to hire new people to work on it. This product is in our core business and so we are afraid them to copy our entire source code, leave the company and sell it.
That said, what we'd like is to restrict access to just some parts of the source code using TFS 2010. The Visual Studio 2010 solution has about 14 projects.
We want to allow access not to every project of the solution and even in any allowed project setup what people would see and change for them.
Any ideas?
Best regards.
You can deny permissions on folders in source control. If you have projects in your solution that needs to be shielded, then you have to create a smaller solution that only has the projects that the new employee has access to.