Here is the setup:
We had a one server TFS solution previously. We split each part out so the DB, TFS and the Build Service each have their own server now.
I manually restored the TFS DBs to the new server. I installed the app tier on the app server and the Build Service on another server. As usual, everything works fine on my computer. However, about half of my team has an issue where the team explorer shows just one project. Most of the team doesn't even have permissions to view this project yet it is all they see.
I had each of them run the tf workspaces ... command to sync up their workspaces to the new server location. I verified permissions. I had one of the affected delete his workspace and create a new one. Same issue. Team explorer only shows one project... that he doesn't even have permission to view. Source control explorer seems to operate fine.
Also, this only seems to affect one project collection. I have not heard anyone on another project collection having this issue.
Suggestions?
Hmm, I'm wondering if you need to do a ChangeServerID.
Related
I am currently working to move TFS from its' current server to a new environment. My team has already completed the steps as seen in this Microsoft Documentation on moving TFS to a new Server.
We have already installed and migrated/restored our SQL Database in the new server and ensured all the prerequisites for TFS were installed. The TFS Admin Console is currently installed and we are trying to configure it by using the existing Tfs_Configure database. That all works without a problem, however, when we go to look at our existing Project Collections, the build service is still "linked", having the TFS Address set to the old server and not the one we migrated to.
I have detached the collections in the old environment and reattached them in the new environment, however, they still seem to be trying to build in the old server. I am reading that we needed to detach them prior to migrating any data over. Did we do something incorrectly, or rather, did we try to detach the collections too late into the process?
You need to unregister the build service that uses the <<oldcomputername>>. Register a build service with the <<newcomputername>>. And do the same for the agent and the controller.
On each build server, open the administration console and stop the
build service.
In the properties for the build service, update the communications
properties.
According to the above screenshot, you could see the build service is configured under project collection level.
Moreover, for vNext build agent you need to remove and re-configure an agent.
To remove the agent:
.\config remove
After you've removed the agent, you can configure it again.
You have to update your build services to point to the new server. For XAML build, you'll have to reconfigure the build controller. For the modern build system, you'll need to reconfigure your build agent(s).
i built an Mobile App on Windows Azure and Visual Studio Community 2015. All Works fine, the local version works like charm. But when i deploy to Azure Mobile App the nightmare began.
After publishing with the option "Execute Code First...." the Site Appears, that an object allready exist in the database with the same Name.
Failure:
[SqlException (0x80131904): There is already an object named 'users' in the database.]
users is the First create table statement in initial script.
in the Global.asax i changed the Migrator Init to:
//Database.SetInitializer(new MobileServiceInitializer());
var migrator = new DbMigrator(new Configuration());
migrator.Update();
i also delete the whole Mobile App in Azure and build one new from scratch, same Problem. it crashes always on the initial script in the Migrations Folder. Local all Work perfect...
i´m serching for a solution since days...i hope anybody can give me an hint...
Reagrds,
Marcus
the hint.
The Migrationname in the database was not the same as in the Configuration.
Deleted all Tables and republish.
I think this is not a normal bug it`s a brain bug :-)
Regards,
Marcus
Feel free to recommend a better title or changes to my explanation below!
I am using Windows Azure Websites (for the first time) and have connected it to a solution in Visual Studio Online (also my first time). I was also able to connect to Visual Studio Online, create a project, throw up a master page and web form connected to a master page and my Azure website updated itself. Great!
My Issue
If I add another project to the solution it seems that this new project overwrites the files in the first one. I can't figure out how to set this up so:
Project 1 -> deploy to wwwroot (happens by default great!)
Project 2 -> deploy to wwwroot/sub/directory/ (doesn't seem to work)
Could somebody explain how to configure project 2 so that when the solution auto deploys to an Azure Website that it goes to a specific location?
Go to the Configure tab for the site in Azure portal.
Scroll all the way to the bottom then add a new application where ever you want like Project2 below.
Basically the 'Project2' part is the URL after the root '/' and the 'site\wwwroot\Project2' is where the actual folder should live under the site root
Download the publishing profile and import it in Visual Studio, then add the application name after your site name like below. Also remember to update the destination URL as well
hope that helps
Up until yesterday, my connection to Team Foundation Service was working perfectly.
A separate requirement caused me yesterday to rename my computer. After that, there were some errors about the workspace which I was able to fix with the TF command, but I can't find anything about this new error, which arose after I renamed the workspace:
Please note that the blacked-out email addresses are all three identical.
I have no idea how to "specify one of the following workspace specs" from a MessageBox! Any ideas?
TFS for years has been among the worst user experiences I've ever seen.
For me it helped to just sign out from TFS via the "Configure Team Projects" window, and then log in again.
Connect to TFS DB and refer DefaultCollection db.
[dbo].[tbl_Workspace] this table is used to store workspace info
[tbl_WorkspaceMapping] this table is used to store mapping created above.
[dbo].[tbl_WorkingFolder] this table is used to store working folder mapping.
Exit your tfs client and perform below steps.
delete your workspaces causing issue from table [dbo].[tbl_Workspace] and [tbl_WorkspaceMapping] and start accessing your tfs client by configuring new workspace.
I had to guess at a "tf" command line argument set, but, I found that the workspace carried the same name as the computer, after renaming both. So I did this to myself.
After using "tf" to change the workspace name from "WIN8DEV" to "WIN8DEVWORKSPACE" this particular problem vanished.
We use TFS2012 and VS2012 (some people use Update1 and some Update2). ). In some people's machines, we get:
TF400324: Team Foundation services are not available from server vstfps\Protection.
Technical information (for administrator):
Page not found.
This happens on any source control access, both in VS2012 and when running "tf.exe get". However, other TFS services work fine, for example work item queries.
I've uninstalled and re-installed VS (this time without Update2), and the problem persists.
I found a similar problem report, though it's somewhat different, and either way has no fix.
Debugging with Netmon, I noticed that affected machines use a different URI:
Good: /tfs/Protection/VersionControl/v4.0/repository.asmx
Bad: /tfs/Protection/VersionControl/v5.0/repository.asmx
What determines the URI the machine uses?
How can I change that?
Workaround: Close Visual Studio and related apps, then delete %LocalAppData%\Microsoft\Team Foundation\4.0\Cache.
Reason: (reconstructed from reports from my sysadmin...)
My TFS2012 RTM server was cloned from an existing server, keeping the same collection GUID. Effects:
The old server had Update1 installed and uninstalled. TFS2012 RTM only supported v4.0 URI, while TFS2012 Update1 added v5.0. So sometimes, clients would get confused and go to the old server, get the v5.0 URI, and keep that cached in ...\Cache\<guid>\LocationServiceData.config.
We've had TFS builds fail with "Can't copy activity logs", since they tried to copy to the old server.
Fix: Change the collection GUID at the new server, by running:
tfsconfig ChangeServerID /sqlinstance:<SQLInstanceName> /databasename:tfs_configuration
afterwards, people need to clean the cache one last time and that's it.