The type ‘xxx’, provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.
While deploying your WCF service on IIS you may get above error because IIS configuration issue. More specifically IIS 7. You might have created a virtual directory pointing to they physical folder where your service binaries are deployed, which will not work. You have to use ‘Add Applicaiton …’ option to make it work. If you have already created a virtual folder not need to delete it there is one more option ‘Convert to Applicaiton’ which can be used to fix this issue.
Hope this helps.
Being a comprehensive Application Life cycle Management system at its core, TFS has various extensibility points. It makes it so flexible that we use the core features to full fill our specific requirements. In this post, I am going to highlight various areas which can be explored. In future posts I will try to deep dive. We can divide TFS’s extensibility capabilities into two categories.
Here we basically focus on re-configuring core TFS functionalities based on our requirements. Following are the areas which can be explored.
- Customizing work item types
- Customizing process templates
- Customizing build process tempate
Here we need to sit down and write some code to develop solutions around TFS. Our solutions are based on TFS SDK. Following is the list of areas to explore.
- Build Activities for customizing builds
- Client APIs
- Event subscriptions (SOAP based)
- Server side event handlers
- Check-in policies
- Custom TFS Background jobs
- Warehouse and cube customization
- Deployment services
- Custom work item controls
- Web Access extensibility
- Diagnostic data adapters
- MTM extensions
- Visual studio extentions
I hope this list might have provided you glimpse of possibilities with TFS. I will go into more details in future posts. Stay tuned.
While working with TFS 2010 we had to go to TFS db directly to get the diagnostic information. TFS DB table named tbl_Command hosts this information. It was sort of a hidden information as if you don’t have access to db, you will not know if it is there; wasting time in finding solutions somewhere else. But with TFS 2012 and TFS 2013 release we also get a separate view for this diagnostic data as part of TFS Web Access portal.
You have to visit : http://<tfsservername>/tfs/_oi/ to land directly on to the diagnostic data.
This view lists all the activities performed by various TFS components like: WorkItem Tracking, Version Control, Framework, Team Configuration Service, Web Access etc.
Activity Log Entry Details
You can even get even more details regarding log entry by double clicking on one. A dialog will pop up for the same. You can get the details like which process, running on which machine, actually generated this event. This is helpful in case this even is generated by some custom tool which is built using TFS client APIs.
This view details about the background jobs which run regularly. So this gives you Job Summary, Job Queue, Job History.
The chart below displays total amount of run time this particular job has taken over the time period. Click on any of the bars in the chart to get the list of jobs contributing to the total.
The chart below displays the number of times a job has run combined with the number of result types for that particular job.
The chart below combines the average queue time and run time for jobs; you can also view how many jobs were run at each hour.
Note that you to see this diagnostic information user should be part of “Team Foundation Administrators” Group. But that will not be a good practice to put everyone into that group. Better option will be to create a new security group in TFS. lets say, “TFS Troubleshooters”. And make specific users/groups part of that group.
We have lot of solutions which are built around TFS 2010 client API. Recently, we planned to upgrade to TFS 2013. When we tried to use new APIs we noticed few anomalies. One out of them was that we were not able to initialize WorkItemStore service object.
We did not change code at all. Only change I did was that project was targeted to .Net Framework 4.5 to accommodate latest TFS Client APIs.
_workItemStore object was initialized to null. After so much time spent into debugging the issue, I found that it was because some of the APIs were still targeted to .Net Framework 2.0, which was giving issue at runtime. To resolve this a little configuration was required. Following snapshot highlights the fix.
The attribute useLegacyV2RuntimeActivationPolicy should be set to true and we were good to go.
Note : This fix applies for TFS 2012 and TFS 2013 client APIs.
If you are facing this issue you must be using Visual Studio 2012 to connect both TFS 2010 and TFS 2012 at the same time. This basically comes when you are connecting to TFS 2010 project. Main cause is corrupted local user cache. It can be resolved easily by deleting the user cache.
Delete everything in this folder on local machine “C:\Users\<user_name>\AppData\Local\Microsoft\Team Foundation\4.0\Cache” and restart VS 2012. This problem will disappear. :-)
Following are the possible reasons
- Different “target framework” in the referred assembly. So make sure refereed assembly project’s target framework should be same as that of referring one. Avoid using .NET x Client framework.
- Long paths can also be a cause for this issue. This can mostly happen when you add project references to a project in a particular solution. The effective resolved path for referred assembly can become longer than expected. Just to highlight the windows path limit is 260 characters (reason best known to Microsoft).
Project collection can only be deleted using TFS’s command line tool named “TFSConfig.exe”. This tool is available under “<TFS Install Root>\Tools” directory. Following is the command syntax
TfsConfig.exe collection /delete /collectionName:”NameOfCollectionToDelete”
This command is applicable both for TFS 2010 and 2012