reminder: Convention over configuration!

http://en.wikipedia.org/wiki/Convention_over_configuration

disable client side button while submitting

the 3 elements i use to achieve this:

we all know it but can never be remined too many times:

Float Clearing

One more popular uses of setting overflow, strangely enough, is float clearing. Setting overflow doesn't clear the float at the element, it self-clears. This means that the element with overflow applied (auto or hidden), will extend as large as it needs to encompass child elements inside that are floated (instead of collapsing), assuming that the height isn't declared.

http://css-tricks.com/the-css-overflow-property/

Exploring IEnumerable

Out of the many useful methods provided in this interface are Skip() and Take().

If you ever need to obtain a subset out of your collection for any reason (eg Pageination) then use these methods in combination:


myCollection.Skip(startPosition).Take(ItemsToReturn)


http://msdn.microsoft.com/en-us/library/bb358985.aspx
http://msdn.microsoft.com/en-us/library/bb503062.aspx

visual studio orange theme

A dark visual studio theme is aimed at getting a bit more contrast and readability over the standard 'out-of-the-box' settings. It also has a few Blackle-esque eco benefits etc..

heres my theme based around the best colour in the world - orange.

Download Visual Studio Orange Theme

example:

here be dragons!

if you're using firefox and cassini web server in your dev environment and finding things are running a little slowly, then apply this update:

1. In the Location bar, type about:config and press Enter.
2. In the Filter field, type network.dns.disableIPv6.
3. In the list of preferences, double-click network.dns.disableIPv6 to set its value to true.

IIS7 and asp.net on windows 7

a quick reminder for anyone trying to setup an asp.net website in IIS7 on windows.
of course, a lot of windows features are locked down (i.e. turned off) so something like IIS7 has to specifically enabled. not only does IIS need to be enabled, but so does the ASP.net component:



more details can be found here:
http://digitizor.com/2009/02/20/how-to-install-microsoft-iis-server-on-windows-7/

Recently, Our QA team noticed that Team System build reports weren’t operating correctly – it appeared that the reports were emitting work items that we knew should’ve been included.

While troubleshooting, our Microsoft contact also noticed our reports where not only missing items, but also including items that shouldn’t have been. They put this down to a label scoping issue and gave us a bit of background regarding how Team Build determines what is in each build, and what might be causing our issue:

“During a build process, at a specific time point a label will be applied to record this build. Next time when we do build again, the build will check the label, and list all changesets that happened after the label. ”

So the first thing for us to check was that our Team Build was targeting the correct repository:



By Microsoft’s own admission this wasn’t going to be the cause of our issue, but ensuring that the Source Control repository mappings are accurate for the mainline and each branch will in turn ensure accurate labelling...

Microsoft product group:
“Label only what you have mapped in the build's workspace. We specifically do not want folks overriding any Core* targets, as that can cause the build to stop working in future updates. While the scope is $/teamproject, the items in the label are only those that you have mapped. The label scope is independent of what is included in the label. The label scope is merely the visibility level of the name.”
And
“The default workspace mapping is almost never appropriate. Certainly for the case of multiple branches within a team project, the workspace mapping should be scoped to include only the folders necessary for the build. In TFS 2005, this is accomplished via the workspacemapping.xml file. In TFS 2008, you can edit the workspace mapping directly in the build definition dialog.”

So for us, the simplest and best answer is a mapping so that the scope of both CoreGet and CoreLabel targets match the desired branch.

At this point we should now only have work items being reported in a Team Build report that relate to the mainline or specific branch repository - and we were, scope issue resolved!!

but... the reports were STILL emitting items we expected to be included!! The final solution was hotfix KB969868:
http://support.microsoft.com/kb/969868