we have just upgraded to TFS 2017 from 2013. We had a custom plugin that ran when we changed the build quality. Since the upgrade it doesn't fire. we have tried changing the required DLLs to use the The 2017 client dlls. but the build quality handler does not trigger the plugin. it uses the Microsoft.TeamFoundation.Framework.Server.ISubscriber interface. We do not get any exceptions as well on the tfs server.
The ISubscriber implementation needs to be recompiled against the TFS 2017 Server as well as Client object model.
And it's important to understand that the new build infrastructure (the non-xaml builds) likely trigger a different set of notifications. At least they're not queryable with the old Client Object Model IBuildServer, you need to use the new REST API.
Without knowing more about your setup (what type of builds, the exact versions of the object model you're binding against, what permissions the TFS Service user has) it's hard to tell where this is going wrong. We have a troubleshooting guide for the TFS Aggregator (https://github.com/tfsaggregator/tfsaggregator/wiki/Troubleshooting) which is also a ISubscriber plugin, it may help you debug your setup.
Related
We have an on-premises TFS instance in our company, and we notice that the sonarqube extension is getting updated automatically. https://github.com/SonarSource/sonar-scanner-vsts
We are worried to have it updated automatically in our production environments, is it really the way it was designed to work? Is there a way to do the updates manually instead or a continuous delivery model?
Yes, this is an expected behavior. In TFS 2017 we added a feature to automatically check for updated external extensions once a day and upgrade them. No way to stop this unless you use a prior version of TFS.
If the account running the TFS Services does not have access to the internet then the jobs will just be marked as failed. They will still attempt to update everyday. To update, you then just have to download the VSIX from the Marketplace and upload it to your local gallery to update the extensions
We used TFS Aggregator to automatic update the User Story's state according to its sons state changes and also to automatic Update User Story's state of other project (if they are related).
Also important to mention that we hire an external freelance to help us doing it. When we tested it on his environment - it worked well. But when deploy it in
our environment - there's no change, the new functionality doesn't work.
what you recommend us to check ?
what can be the reasons for this integration problem?
What actions should we take?
Your advises are more than welcome!
First, try to follow the steps of installation on this website to install the plugin: https://github.com/tfsaggregator/tfsaggregator/wiki/Install
If it still doesn't work. Here is the troubleshooting page you can refer to: TFS Aggregator Troubleshooting:
You are using the right version of this server side plugin for the
right server. You can get multiple releases of this plugin at website
https://github.com/tfsaggregator/tfsaggregator
You have updated a work item that triggers a rule. (The TFS
Aggregation only works once a work item that has aggregation rules on
it is updated. This may change in a future version.)
If the rule navigates between work items, work items have a proper
Link (e.g. Parent-Child).
You copied the DLLs and the Policies file to the plugins location on
all TFS Application Tier Servers (Usually at: :\Program
Files\Microsoft Team Foundation Server {version}\Application Tier\Web
Services\bin\Plugins)
You have valid names for source and destination fields in
TFSAggregator2.ServerPlugin.policies.
When you saved the file you saved it as UTF-8 encoding (in Notepad++
it is called “utf-8 without BOM”).
You have given permission to the user running the plugin, e.g. add
the "TFS Service Account" to the Project Collection Administrators
TFS Group.
You may have to do this from the commandline using tfssecurity
/collection:http://server:8080/tfs/DefaultCollection /g+ "Project
Collection administrators" "LOCAL SERVICE" if your service account is
either LocalService, NetworkService or any other Windows Well-known
identity, since they are no longer shown in the permission UI.
When using the Impersonation option, make sure the user executing the
plugin (generally the TFS Service account) has the "Make requests on
behalf of others" permission at the server level
If you upgraded your TFS from 2013.x to 2015.* and from 2015rtm to
2015.1 and did not uninstall the TFS Aggregator before doing this TFS upgrade the aggregator does not work. Remove the TFS Aggregator from
the TFS 2013 Program Files folder or run the uninstall of the TFS
Aggegrator (backup your policies!). Then re-install the TFS
Aggegrator setup or install manually for TFS 2015 as described here.
Every TFS version has its "own" assembly for the aggregator so it is
important to use the right version against the right TFS.
I wish we could use multiple build controllers on the same machine because we have many team project collections but they're not used at the same time so there's no real performance issue here and most of our build servers are not used for extended period of time. I know it's possible to do this with TFS 2010 and TFS 2012 (see following post) but it's an unsupported feature.
Anyone can tell me if it's now officially supported with TFS 2013, I've not been able to find any useful information about this.
This is still an unsupported feature. This feature would be loudly trompetted should it arrive.
On the chances of this arriving in the TFS 2013 updates, I don't expect it. Maybe with TFS v14 (they're skipping v13) or maybe the version after that?
Make your voice heard on UserVoice:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2037679-remove-one-one-binding-between-collection-and-buil
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4417771-use-a-build-controller-over-more-than-one-team-pro
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3872254-tfs-2012-possibility-to-have-more-than-one-build
Update
A new build system was introduced in TFS 2015 and Visual Studio Team Services. It's agent based. doesn't have Controllers and you can install multiple agents on a single machine.
Agents are grouped in Pools and live at the Server level, allowing you to use them across collections.
I want to do daily migration of TFS changes to a ClearCase system. I was going to try out TFS Integration tools but I can't get any of the toolset pieces to work. What are the requirements to run this app? I have VS 2010, TFS 2010 and Sharepoint 2010 installed. The assemblies it's trying to load don't seem to be present in VS2010 and I don't if it requires VS 2008 or not. Anyone ever had this running? I'm migrating from TFS to CC. Not the other way around.
Update:
I've been using this tool to sync TFS 2010 changes back into a UCM ClearCase implementation at the client. It has been going poorly. The tool should be clearly marked as Beta or even Alpha. A peek into the code reveal around 100 TODO's and "This needs to be fixed". I have spent a good deal of time trying to iron out some of the issues and have made progress. My suggestion is before using this tool on mission critical projects, spend at least 3-4 weeks evaluating it in your environment. When it works, it works pretty well with moving changes.
I don't know much about how to access TFS2010 elements, besides "check an individual project for pre & postbuild steps either by loading the project in visual studio or manually reading the project file".
If you need Sharepoint assembly, this technote describes the requirements.
And I don't think an automatic import utility exists (from TFS2010 to ClearCase 7.1.x), as this technote mentions:
Change request (RFE) RATLC01005874 had been submitted requesting a conversion utility to export source code from Microsoft Team Foundation Version Control (TFVC) to ClearCase;
however, the decision was made by Product Management to exclude the requested feature from future upgrades and releases due to the significant architectural changes required to implement the solution.
The right approach is to manage to list the content of relevant labels for a given scope, and make a clearfsimport into a ClearCase view, with a full label applied right after it.
You don't need TFS (server), VS or SharePoint installed. You will need a SQL server for the core platform. Then you will need the various assemblies for TFS, which you can get by installing the Team Explorer component (it's on the TFS install media).
We decided to go with the TFS Integration Platform. It allows us to sync TFS work items back into ClearCase when ever we want. It provides the level of integration we needed to keep the traceability. The TFS to CC integration is bleeding edge, but it works enough for what we need. (Syncing work items and user check ins.)
I'm asking this question because I haven't seen it documented anywhere.
We are using a combination of Team Foundation Server 2008 and Team Explorer 2005.
Is it possible to deploy a custom check-in policy that works in such an environment ?
Obviously, the custom check-in policy contains some code that must run on the client-side (in order to display help, etc.). So it should use the Microsoft.TeamFoundation.VersionControl.Client assembly that comes with Team Explorer 2005.
But, my sense tells me that, in order to be effective, a check-in policy should be enforced on the server itself (for example, to support checking-in changes from the command-line or using the raw Web Services API). So, there, it would have to run against the Microsoft.TeamFoundation.VersionControl.Client that comes with Team Foundation Server 2008.
So, is it possible to build a single custom check-in policy that takes the most recent version the Microsoft.TeamFoundation.VersionControl.Client assembly (2005 on the client and 2008 on the server)?
Or do I have to build two custom check-in policies, one for the client and one for the server ? Would that even work ?
Or do custom check-in policies only ever exist on the client side ?
The custom check-in policies only exist at client-side, and will only be evaluated client-side. If the DLL is missing on the client computer, TFS will complain, but provide a dialog that allows the user to override the error and check in anyways.
No, it's not required. However, it makes things much easier. Using the latest Power Tools you can store check-in policies in source control and have them deployed for "free."
A walkthru with screenshots is on Brian's blog:
....Since the day we introduced those features, customers have asked for a way to distribute custom components like these to clients rather than having to manually install them. Well, I'm happy to say that this new release of the Power Tools does just that!
Due to the fact that downloading custom components and running them on clients can be dangerous, there's a fair amount of care taken and some configuration necessary to enable it. Custom components for a Team Project are checked in to a new "special" folder called $//TeamProjectConfiguration. Let me show you a few screen shots and that will help walk you through how this works....