Jon Fowler's Blog

On a recent TFS consultancy job, I was asked to monitor how long some builds spent waiting in the Build queue before Starting.

My plan was to use the TFS API  to query all builds with a status of ‘Queued’ and monitor the wait times.

I wrote the code and everything seemed to work fine.  However, after capturing a number of wait times and comparing them to the overall build times I noticed that the times did not match together.

In fact a build that was estimated to complete in 2 hours; took more than  6 hours and did not spend any time ‘Queued’

How?

The Build Controller distributes builds across multiple agents  and will start one build per build agent. (given you haven't changed the default MaxConcurrentBuilds setting ).  i.e If you have 3 build agents and you start 3 builds then the controller will set 3 builds into ‘InProgress.’  If you start a 4th build the this build will be ‘Queued’

This works fine given that any build agent can run any build definition

Unfortunately it does not take into account ‘Tags’ that may force certain builds onto specific agents.

Given the same conditions of 3 build agents:-
If you tag  a build agent  so only certain builds can use it and then start 3 builds that should only run on this tagged build agent. –> well you would expect that only one build would be set ‘InProgress’ and the other 2 builds would remain ‘Queued’ until the build agent finished the 1st build.

However the actual behaviour is that all 3 builds change to ‘InProgress’ at the same time; one per the MaxConcurrentBuilds setting on the build controller);  but only the first build is actually doing anything. The second two builds are stuck waiting to be allocated an agent .

Side Affects

You look at your dashboard and see a list of builds ‘In Progress’ that are actually blocked waiting for a build agent.

On the above screen-shot, only 213 is actually running on Build Agent 1. (214 and 215 are blocked waiting for agent 1 to become available)

Worse than that is 217; that can run on any build agent; is blocked in a ‘queued’ state when there are 2 idle build agents that could be running this build. However, It cannot start because the MaxConcurrentBuilds value of 3 has been reach.

Conclusion

Be very careful with the use of Tags. In future I will try and avoid tags when it could introduce the above bottleneck.

Additionally when attempting to use the TFS Api  to capture metrics on wait times then you cannot rely on Queued build only.  Instead I’ll query all builds assigned to a controller; and then filter out the list of builds that have been assigned a build agent –> This will give me the accurate list of builds pending.

The new Team Explorer in Visual Studio 2012 has taken me some getting used to.

When working with source control in VS2012, there is no longer a ‘Pending Changes’ View that is independent  of team explorer.  I missed it because now I must navigate 3 menus into Team Explorer to find out what files I have modified.

That was until I found the new Solution Explorer filters.  Pressing  Ctrl+[, Ctrl+P will filter the solution explorer to show only checked out files. Tap again to remove the filter. Sweet!

Another interesting shortcut is Ctrl+[, Ctrl+O that filters solution explorer to show only files you have open

I installed Visual Studio 2012 release candidate yesterday.  My quick n dirty conversion of Prism failed to compile.

I’ve fixed the issue and released a new version on Codeplex http://metroprism.codeplex.com/releases/view/87705

During my original conversion, I used ‘CoreWindow.Current.Dispatcher’  (to try and dispatch a command on the UI context). In 2012 RC, The ‘Current’ property is no longer present; so instead I have replaced with CoreApplication.MainView.CoreWindow.Dispatcher.

So Visual Studio 2012 RC is out …time to open up all our projects and see what no longer works.

Hit an issue with my unit test projects, the namespace in these projects, ‘Microsoft.VisualStudio.TestTools.UnitTesting’ has been renamed to ‘Microsoft.VisualStudio.TestPlatform.UnitTestFramework’

A quick ‘Find & Replace’ updated all the references …and I thought the job was done until the compiler reported:

‘The type or namespace name 'ExpectedExceptionAttribute' could not be found (are you missing a using directive or an assembly reference?)’

It appears this attribute has been either moved or removed from the framework.

Possible because there is an improved mechanism for Asserting exceptions now. Its possible to replace the [ExpectedException] attribute with the following test code:

Although this is a fantastic improvement over the attributed version; it leaves me in a predicament of having lots and lots of unit tests to fix-up <groan>

If anyone discovers that this attribute does exist somewhere please let me know

Quick Answer: It has a hidden file attribute applied. Changing the folder options to ‘Show Hidden Files and Folder’ revealed the SUO file adjacent to the solution file .

When you open a Visual Studio Solution file, i.e. MySolution.sln,   a corresponding MySolution.suo file is generated. This file is constantly updated with the current state of Visual Studio (i.e. which windows you have open). When you close and reopen Visual Studio, the previous state is reloaded from this file.

Unfortunately from time to time this can lead to problems. For example, It is common for Visual Studio to crash when too many designer files are opened simultaneously. Because the state is remembered in the SUO file ; it can then become impossible to re-open the Visual Studio solution because it will result in a re-occurring crash. When this occurs I usually just delete the SUO file; and Visual Studio will re-open a solution afresh; without any retained state.

However in Visual Studio 11 Beta I could not find the SUO file? Its normally would be found in the directory adjacent the solution file; yet I could not see it. I ran a search for SUO files on my C: drive and found none.

Thoroughly confused I opened ProcMon.exe and watched what files Visual Studio was loading as I opened my solution. A quick search found the suo file where I had expected it; adjacent to the solution. However the file had a hidden attribute applied to it so I couldn’t see it with the default folder options in Windows 8.

Changing the folder options to ‘Show Hidden Files and Folder’ revealed the SUO file.

Importing namespaces in XAML is different in .Net Metro applications compared with WPF. The difference is subtle and caught me unawares…

In WPF, one imports a namespace using.

<Grid xmlns:Core="clr-namespace:Namespace;Assembly=AssemblyName"

This has changed to :

<Gridxmlns:Core="using:Namespace”

Note the ‘using:‘ rather than ‘clr-namespace:’

So its similar to syntax of import statements in c# code behind. The bonus is that you no longer need to specify the assembly name ( it is handled for you automatically).

This post is part of a series of ‘Lessons Learnt’ from  a recent conversion of Microsoft.Practices.Prism to Net Metro Prism. See  here for related posts

I got stumped on an issue with delegates whilst converting Prism to Metro  … In metro, A System.Delegate type doesn’t have a Method property. How can that be!?

Background

One of the internal classes in the Prism library (DelegateReference.cs) acts a weak Delegate reference… It takes a Delegate type parameter in its constructor and records all of its information . It then allows the delegate to be freed from memory until the point it is meant to be fired; at which point it re-creates the delegate using the information it recorded.

I believe its used as part of the EventAggregator functionality to avoid having lots of active event handlers .

Problem

The existing  constructor attempts to record the MethodInfo from the Delegate using the following line of code.

string methodName = @delegate.Method;

In .Net for Metro this Method property is not exposed

……!?

My initial thought was that the delegate must know which method to invoke; so even though it is not exposed on the abstract Delegate class; it must be recorded a private variable. Perhaps the derived class will expose the method.

So I started the debugger; and used the immediate window to inspect the delegate as it was passed to the ctor.

Notice that you can see the Method property – [void DoEvent(System.String).

If I look at the base System.Delegate class then I can also see the same method:

The property is there and i can see the event. Yet intellisense and the compiler won’t allow me to access it.

…..!? Does anyone know what is causing this?

My initial thought is that there is a mismatch between the assemblies that Visual Studio/Compiler is using; and those that are in use from the GAC at runtime.

Workaround

Instead of using a strongly typed Delegate; I referred to it using the dynamic keyword instead. This avoids the compiler checking; and allows me to write the code that queries the method property. As the Method property is in memory when running the app the code works as it should.

I recently upgraded a WCF Data Service project to WCF Data Services 5.0  for OData v3. This upgrade has support for accessing your EF Code First entities via a Wcf data service.

There’s a good blog post on MSDN by Glenn Gailey with details on how to upgrade.

However, I started my upgraded service and got this rather unhelpful error message:

The server encountered an error processing the request. Please see the service help page for constructing valid requests to the service. The exception message is 'On data context type '<type>', there is a top IQueryable property '<propertyName>' whose element type is not an entity type. Make sure that the IQueryable property is of entity type or specify the IgnoreProperties attribute on the data context type to ignore this property.'. See server logs for more details.

The cause of the problem was failing to remove all references to  System.Data.Services and System.Data.Services.Client from all my projects.

Following the guidance I’d removed all references to System.Data.Services.* from the main WCF data service project; but I had missed the indirect reference in my “Entity Model” Project.  Some entities  were marked with the [DataContractKey()] attribute; thus leading to the stray reference.

Removing all reference to System.Data.Service.* and replacing with Microsoft.Data.Services.Client.dll fixed the error.

(assemblies can be found in %programfiles(x86)%\Microsoft WCF Data Services\5.0\bin)

This post is part of a series of ‘Lessons Learnt’ from  a recent conversion of Microsoft.Practices.Prism to Net Metro Prism. See  here for related posts

Where is Type.GetTypeInfo()!?

Most members from the System.Type class have been moved to the System.Reflection.TypeInfo class. All the documentation suggests you can get an instance of this type calling Type.GetTypeInfo(); but its not there?

>> Its an extension method and to use it you must include an import statement to System.Reflection:

using System.Reflection

Doh!

The exe and assemblies can be found under C:\Program Files\WindowsApps  (need to add permissions to view folder)

Deployed Metro apps access application settings and runtime state information in C:\Users\<username>\AppData\Local\Packages

The  appxmanifest.xml can be found under C:\ProgramData\Microsoft\Windows\AppRepository  (need to add permissions to view folder)

Your application can be identified by matching the folder name with the name you provided in the Package.appxmanifest file included in your project.

Open Solution Explorer –> Package.appxmanifest:

Open the Packaging Tab:

In File Explore navigate to C:\Users\user\AppData\Local\Packages. –> Locate folder via name