Have used several times with different customers and it worked great for me (and them). Only complaint would be that it can't work within or on top of the 'native' Builds node... but understandable why it can't.
Hi! We have not seen this before. Can you tell us some more on your setup. Do you have permission to change the team project you are changing? Does this happen on all team projects? Is it SP1? Feel free to email me directly at terje at osiris.no
Installed and when tried using the Refresh button in the context menu, it threw "TF30063: You are not authorized to access '[TFS]\[COLLECTION NAME]' even though I have logged as a TFS administrator. Any idea how to resolve this?
I know, I know, I know .....
I want it too!
Lack of available time has delayed this.
I got a prototype up and running, the changes in the Team Explorer are more than expected and less documented. I will try to release a beta in the near future. It will have to load the builds itself instead of piggybacking the normal build node, but it works, althought a bit slower. The first beta will only have the displaying of builds, the second will add the actions too.
Since there's no support for VS 2012, I attempted to use it with my old 2010 configuration; however, it didn't appear to do anything with my builds (already organized using a dot-based (".") hierarchical structure) and I can't find any options anywhere to configure it.
Has this extension been tested with the TFS 2012 GDR update for VS 2010?
The extension should work nicely with the latest GDR update. I am surprised that you dont get any response there.
I assume you see the node "Inmeta Builds Explorer". If there are no folders below that one, that sounds very strange. If you right click that node and choose "Refresh" it should rebuild the tree. In the same right click menu you find the Options dialog. In there you can change the seperator (but '.' is default), anyway - if you change it (or anything really), you can check if you get a file named "Inmeta.VisualStudio.BuildExplorer.Settings.xml" in the folder BuildProcess Templates in your Team Project source control. If you get that file, you have the right access in order.
If the folders appear after a manual Refresh, but not automatically when opening a team project, try to increase the delay time in the Options menu.
If it still don't work, email me at terje.sandstrom at inmeta.com and we can debug this offlist.
I installed this tool and it works great for someone that works with the build definitions in Team Explorer. My issue is that many of my users view and manage build status and progress in VS build explorer, not team explorer. Are there any thoughts for similar functionality for build explorer, or does the build explorer build dropdown just provide a flat list that can't be tailored in any way? The way our build are setup, I am continously adding new build definitions and the list just keeps growing. I understand that I could change the strategy to more static build definitions, but I want to explore other options as well.
Adding to my initial post that the Community TFS build Managers has a feature that makes it possible to remove disabled builds from the build list, but still does not provide the same type of structuring as Inmeta Builds Explorer. It however does help me in reducing the list of builds and together with Inmeta Build Explorer helps in the total build management process.
Sorry about the late answer.
On your first item, afaik we can't extend or change the Build Explorer.
So, your second item could be a better approach, that is integrating the folder view into the Community Build Manager (The latest release of the CBM also integrates into the Team Explorer, as a link there under Build.) I have discussed this with Jakob, my colleague who has written quite a bit of that code, and we have discussed merging the treeview into the CBM, using the same settings. It only requires some more time available to do it .......
This excellent tool could be even better, if I could switch between different "views".
Having a loot of builds named by Product.Branch.Type makes it simpel to browse the tree most times, but sometime I wich I named then Builds like Branch.Product.Type or even Type.Product.Branch.If I could define "views" to controll how the tree is build, I could define a view "Product.Branch" as "%1.%2.%3" and a "Branch.Product" view as "%2.%1.%3"
That is a great idea!
I assume you mean that all the views should be visible at the same time, and that they are named, and also then define the top level nodes of the tree.
Should there be a default view, where the view-node is not shown, to make it faster to go down the tree ?
I like to be able to see the products listed as top level nodes, without having to expand a possible view level. What do you think ?
Another way is to have multiple views, but only one shown at a time. Selecting between them could be through the context menu. That would make the products (or whatever item you have as top) easily seen.
I just installed this explorer and it looks good but I only have an issue with missing the Clone Build Definition option. Which is very useful to create very quick. Please can you fix this with the next release?
The reason it was not included is that it is a part of the TFS Power Tools, and we didnt want to include things the user may not have installed. But I do agree, it is very useful. We will add a check to see if the TFS Power Tools is installed and add that command if it is.
Thanks for the suggestion !
I've been getting the following error for a while now.
Getting z:\<source dir>\BuildProcessTemplates\Inmeta.VisualStudio.BuildExplorer.Settings.xml
z:\<source dir>\BuildProcessTemplates\Inmeta.VisualStudio.BuildExplorer.Settings.xml: Could not find a part of the path 'z:\zmsource\BuildProcessTemplates'.
I dont have a z drive mapped anywhere, & i can't find any reference to a z drive in the registry. Can any shed some light on this?
We create a temporary workspace with the name "InmetaVisualStudioBuildExplorerTempWorkspace".
That workspace is mapped to a local path given by your Temp path, this variable selects the first of these:
1. The path specified by the TMP environment variable.
2. The path specified by the TEMP environment variable.
3. The path specified by the USERPROFILE environment variable.
4. The Windows directory.
I would guess your temp path is set to "z:" by one of these variables. You can check them first to see if that is the case.
There are two issues here:
1. We haven't managed to remove it, it doesn't seem to be possible to hide the existing nodes, or replace them. If anyone has any knowledge to share about it, it is very welcome. However, they must not be replaced, just hidden, because.....
2. The power tools and possibly other extensions could assume that the original nodes still are there, and add their functionality to them. We are not able to know when we are called in the initialization sequence of (afaik), so things could happen both before and after our initialization code is running. However, if they are just hidden it could work, but then, we need to know how :-)
One possible workaround could be to lift the Build Explorer above the Build node. We took the humble approach and placed it below.
We are releasing a new update during this weekend, just a few minor things more to handle :-)
One possible workaround could