January 2009 Archives

Google's "Don't be Evil" mantra seems to be rapidly falling by the wayside.

I was doing a bit of a tidy-up on my laptop today (Sony Vaio purchased mid-2008) and noticed in Programs and Features something called "Browser Address Error Redirector". The only menu option was "Uninstall/Change" and only by hunting down into the registry was I able to find the uninstall string:

regsvr32 /u /s "C:\PROGRA~1\GOOGLE~1\BAE.dll"

Now, not only does this hide from the user (by not specifying the manufacturer) that it's from Google, but, the name almost makes it sound "official". Pah. To make matters worse, the uninstaller just unregisters the DLL, leaving it sat there on the PC. Erm, that's *not* uninstalling!

Another comment on this: http://googlesystem.blogspot.com/2007/05/googles-browser-address-error.html

I found shipitontheside.com recently and more specifically the entry Three Stupid Software Startup Mistakes, and knew that I had to pass comment on it.

Every. Single. Word. Is. True.

Except for the title.

I initially wrote this post with the title "Three Stupid Startup Mistakes", revised down from shipit's title, then revised it down further to "Three Stupid Mistakes" as above as they really do apply to any company, whether software producing or not, startup or not. I've seen all three in companies of varying sizes.

If you have an ASP.net web site (Visual Studio 2005 heritage from when project files disappeared), you might be using Visual Studio to build it into an MSI Installer in your CruiseControl.NET build server. If you're not, lucky you! :)

If you are, it's useful to be able to see Visual Studio's build output in the build log CC shows you, so try this:

  <target name="build.devenv90.website">
    <exec program="${DevEnvExe.90}">
      <arg value='/Rebuild release "C:\BuildServer\VSS\WebSite\Website.sln" /Out "c:\buildserver\vss\website\vs_errors.txt"' />
    </exec>
    <trycatch>
      <try>
        <loadfile 
          file='C:\buildserver\vss\WebSite\vs_errors.txt'          
          property='VisualStudio.Output'
        />
        <echo message='${VisualStudio.Output}' />
      </try>
      <catch>
        <echo message='*** Visual Studio Output Failed ***' />
      </catch>
    </trycatch>
  </target>

The trick there is using the loadfile task to pull Visual Studio's output into a property and then echo-ing it. Nothing more exciting than that really!

Another note to self - how to implement IComparable<T> in a class.

I seem to recall that the msdn documentation for this was poor, so this is definately good.

Post titles cannot have <T> in them, i.e. Anything that looks like markup as this gets rendered as written and thus the <T> does not show.

Take, for example, C# Static variables of Foobar<T> are per T, until I edited the entry just now so that the <T> part of the Title read (as displayed in the MT Edit Entry screen) &lt;T&gt;, the "<T>" did not appear in the page title. Grrrr!

At the moment one of my projects is to harmonise all our build scripts so instead of having one per project (DLL's, Websites, WebServices, WinServices, EXE's) we have a StandardDLL, StandardWebsite, StandardWebService,.... This will take us down from over 50 build scripts to approximately 10-15 once "system" ones are included.

One thing that caused me a small problem was the fact that, within our DLL's, we have different levels of coverage attained and there is no realistic likelihood of the level of coverage being harmonised anytime soon (Yes, yes, ideal world = 100% coverage, etc). So, how to achieve this when using a standardised build script called StandardDLL.build?

The Build Script

<target name="ncoverage">
  <ncover program="${ToolsPath}\ncover\1.5.6\NCover.Console.exe"
    commandLineExe="${ToolsPath}\nunit\bin\nunit-console.exe"
    commandLineArgs="${ProjectName}.Test.dll /xml=${NCoverOutput}\${ProjectName}_Coverage.xml /labels /nologo"
    workingDirectory="${ProjectBasePath}\src\test\bin\${configuration}\"
    coverageFile="${NCoverOutput}\${ProjectName}_Coverage.xml"
    logLevel="Verbose"
    logFile="${ProjectBasePath}\src\test\bin\${configuration}\ncover.log"
    excludeAttributes="CoverageExcludeAttribute;System.CodeDom.Compiler.GeneratedCodeAttribute">
      <assemblies basedir="${ProjectBasePath}\src\test\bin\${configuration}\">
        <include name="${ProjectName}.dll" />
        <exclude name="*.Test.dll" />
      </assemblies>
  </ncover>

  <ncoverexplorer 
    program="${ToolsPath}\NCoverExplorer\ncoverexplorer.console.exe"
    outputDir="${NCoverOutput}\" 
    satisfactoryCoverage="90" 
    reportType="4" 
    failMinimum="true"
    projectName="${ProjectName}"
    xmlReportName="${ProjectName}_Coverage_Report.xml">
    <fileset>
      <include name="${NCoverOutput}\${ProjectName}_Coverage.xml" />
    </fileset>
  </ncoverexplorer>
</target>

The key bit is marked in bold, the "satisfactoryCoverage" node. I needed a way to have this configurable on a per-project basis, but without having to specify it for all projects (Just to be awkward!).

The Solution
It turned out the solution was quite simple; firstly replace the hard-coded "90" with "${satisfactoryCoverage}", i.e. a nant property. Secondly, add a new action just above the ncover node, i.e. between it and the <target> parent node that is as follows:

<if test="${not property::exists('satisfactoryCoverage')}">
  <property name="satisfactoryCoverage" value="90" />
</if>

This node makes sure that the satisfactoyCoverage property exists and is set to a default value of 90. Now, onto specifying it as a custom value when required:

<tasks>
  <nant>
    <buildFile>C:\BuildServer\BuildScripts\StandardDLL.build</buildFile>
    <buildArgs>-D:satisfactoryCoverage=85</buildArgs>

That's a snippet from the <project> node for a given project in the ccnet.config file. By specifying that build argument, the satisfactoryCoverage for that project will be 85%, rather than the standard 90%

"The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>)"

See the solution here: Controls Collection Cannot Be Modified Issue with ASP.NET MVC RC1.

I've come across the issue of not being able to mix modifying the Head's .Controls collection when there's <%%> elements in it, before. Nice to know there's a solution!

From a question I proposed an answer to on stackoverflow.com.

If you've ever looked at the properties of a user in Exchange you'll have seen a list of strings like:

smtp:john.smith@company-name.com
smtp:john.smith@companyname.com
SMTP:john.smith@company-name.co.uk
smtp:john.smith@companyname.co.uk
x400:C=UK; A= ;P=Test;O=CompanyName;OU=Sales;S=John; G=Smith;
x500:C=UK; A= ;P=Test;O=CompanyName;OU=Sales;S=John; G=Smith;

Now, imagine that these were given to you as one long semi-colon separated string... How would you split it up into say an array, or a List<string> that contained one each of those lines above, per element.

You could use Regular Expressions, but, now you have two problems. I'm not going to copy my solution here lock-stock, needless to say it underwent multiple revisions and probably isn't the best one, but it seems to have made the person that asked the original question happy, and that's job done for me :)

Exactly what it says in the subject line!

<vssget
  username="nant" 
  password="nant" 
  localpath="${LocalPath}"
  recursive="true" 
  replace="true" 
  writable="true" 
  removedeleted="false" 
  dbpath="${DBPath}"
  path="${VSSPath}"
/>

For some reason, that I've yet to discover - and doesn't appear to be documented in the nantcontrib documentation, the "localpath" and "dbpath" properties will merrily accept nant property expansion, but the path won't. Grrr! Thusly I get an error as below when I run the script:

The "path" and/or "version" is not valid.

Another "note to self" type entry, but, the article "Setting up CruiseControl.NET to be a Continuous Monitoring Server" from CodeProject looks quite ingenious.

There's the risk of trying to "use a hammer to put a screw in the wall" with an approach like this, but for a simple monitoring solution, CruiseControl would certainly seem to be a genius of a solution. Something I'm now going to have to consider in great depth!

I discovered a comment about a thir of the way down Eric Lippert's recent blog entry, where he asked people to share their experiences of discovering something non-intuitive about programming languags:

Discovering that the static variables of generic type Foo<t> were per T was interesting (and I see why they are that way) just that it was quite subtle when I first hit it.

What would you know, it's true:

    class Program
    {
        static void Main(string[] args)
        {
            int intGenericClassId = GenericClass<int>.GetId();
            int boolGenericClassId = GenericClass<bool>.GetId();

            print(typeof(GenericClass<int>).Name, intGenericClassId);
            print(typeof(GenericClass<bool>).Name, boolGenericClassId);

            GenericClass<int>.SetId(3);
            Console.WriteLine("Set <GenericClass<int> to Id of 3");

            intGenericClassId = GenericClass<int>.GetId();
            boolGenericClassId = GenericClass<bool>.GetId();

            print(typeof(GenericClass<int>).Name, intGenericClassId);
            print(typeof(GenericClass<bool>).Name, boolGenericClassId);

            Console.ReadKey();
        }

        private static void print(string typeName, int value)
        {
            Console.WriteLine("Starting value of Int for {0}: {1}", typeName, value);
        }

        internal static class GenericClass<T> where T : struct
        {
            private static int _id = 0;
            static GenericClass()
            {
            }
            public static int GetId()
            {
                return _id;
            }
            public static void SetId(int value)
            {
                _id = value;
            }
        }
    }

Back in February of last year, I commented in "Delusional Ramblings of an Angry Coder" about the delusional, inaccurate and down-right (in places) witterings of some guy called Mark Gordon who seems to get a kick out of spouting off-topic vitriol about the demise of Foxpro and Classic VB on every posting written on Somasegar's Weblog.

Guess what folks, he's still at it. His latest "toys thrown out of the pram" moment is on display where he states that "Reflection was just some nonsensical glue code to workaround the normal bugs in VS". The context for the posting is some of the enhancements for those who develop against Office that will be available in VS2010, mainly the death of PIA's, named parameters and the removal of the need to use System.Reflection.Missing.Value. Not one of those is actually anything to do with VS itself.

Mark Gordon, fail.

Le sigh.

Found via a comment on the IE Blog.

I don't know if it'll work for you, but, I just disabled the "Research" toolbar through "Manage Add-ons" and immediately Internet Explorer 7 loads a lot more quickly.

Worth a try!

A couple of articvles that are worth reading that have been sat in open tabs since my recent bout of NCover based learning:

Reporting on NCover Exclusions (Basildon Coder)
Advocating the use of code coverage

How cool is this: Global is the new private.

A real-time always up-to-date display of just how much each of the current javascript frameworks pollute the global namespace. Genius.

The Playmobil Security Checkpoint is funny enough in and of itself. What a toy to buy a child.

The reviews on amazon.com, further down that page are worth their weight (and then some!) in gold though. A couple of snippets:

• "My 5 year old son pointed out that the passenger's shoes cannot be removed."
• "Wow! So much better than playing school or house for brainwashing"
• "I am holding out for the release of the Guantanemo Playset. Hopefully this will come with an extrordinary rendition option.

Genius. Sheer genius!

One of the most frustrating things about Web References, Resource Files and their brethren is that they result in NCover (by default) showing a stupidly low Code Coverage %. There's an easy way around this, particularly if you're using TestDriven.net

Create an attribute called CoverageExcludeAttribute:

using System;

[AttributeUsage(AttributeTargets.All)]
public class CoverageExcludeAttribute: Attribute {}

A good place to put it is in a shared assembly, or in your AssemblyInfo.cs if your class/project is somewhat monolithic. Now, every class or method that you decorate with this attribute will be ignored by NCover (when run via TestDriven.net). You can also make any nant build tasks you have running in CruiseControl do the same:

<ncover program="NCover.Console.exe" commandLineExe="nunit-console.exe" commandLineArgs="My.Test.dll /xml=Coverage.xml /labels /nologo" coverageFile="Coverage.xml" logLevel="Verbose"
logFile="My.log"
excludeAttributes="CoverageExcludeAttribute;System.CodeDom.Compiler.GeneratedCodeAttribute" registerProfiler="false">
</ncover>

Note the second attribute that's in there - "System.CodeDom.Compiler.GeneratedCodeAttribute", that's the one that automatically excludes any code that Visual Studio / other MS tools automatically generates, leaving the "CoverageExcludeAttribute" for when you need to (judiciously!!) apply it.

Not long ago my Immediate Window went missing, couldn't be found, etc,. How very annoying!

Therefore, useful Keyboard shortcut of the year: CTRL-ALT-I

Back in extJs: getClientRects() error I mentioned that for some reason the bottom row of one of my grids was non-editable. The grid concerned only had two rows and sorting it at least once, on any column, resolved the issue and made both rows editable. I've since confirmed that adding another row to the grid doesn't fix it, the last row is still non-editable.

Various things I've tried doing to solve this:

• Calling fireevent on the headermousedown event (which was never going to work, stupid me!)
• Calling fireevent on the headerclick event
• Calling fireevent on the headerdblclick event

Nothing seems to work. More frustratingly, nothing in Google seems to provide me with the answer either. Aaaaaaargh!!!

I've recently been building out a new Windows 2003 test environment on a Virtual Server and made the fatal flaw of installing .net 3.5 before installing IIS. Doing this makes any page processed by the .net framework through a "404 Not Found" error message. D'oh

The simple solution is to open a command prompt, navigate to "%windir%\Microsoft.Net\Framework\v2.0.50727" and run "aspnet_regiis -i -enable". This should work for other versions of the framework, but with the relevant vx.x.xxxxx substituted into the path.

More of a memo-to-self than anything else, but:

How To: Hash Data with Salt (C#/VB.NET)
Paj's Home: Cryptography: Javascript MD5 (Which despite the name does contain info on creating SHA-1 hashes using Javascript)

The only question I need to adequately answer is; is it really worth hashing the password that's sent over the wire by pre-processing it with javascript. For a login conducted over HTTPS, I suspect the answer is an emphaatic no.

Having followed the saga of Portman and their battle with BrewDog to its latest installment, I have to say I agree wholeheartedly with BrewDog.

Portman have, for as long as I can remember, been a pointless example of the worst "nanny-state" drivel this country has to offer. This is my opinion as a former-licensee, so it's not a "Joe Public" opinion, more one that's been shaped by working in the licensed trade in the past.

I for one would never have known that "Speedball is the name given to the potentially lethal practice of combining heroin and crack cocaine" unless Portman had made a fuss about this product. They're a self-fulfilling prophecy.

For some reason, some paths (there doesn't appear to be a determining factor as to what they are) when passed to the MySql.exe process cause an error message similar to:

ERROR: Unknown command '\b'

Unfortunately, it doesn't seem to be limited to this specific '\b' - as that seems to be whatever is immediately after the "C:" in the path to the sql file to process, so:

mysql.exe -uUSERNAME -pPASSWORD -hHOST_IP_ADDRESS DATABASE_NAME_HERE -e "source c:\buildserver\source\Databases\DatabaseName\src\sql\schema\tables\tableName.sql

Generates the message '\b', if the c:\buildserver folder is renamed to aardvark, the message "ERROR: Unknown command '\a'" is returned.

The Solution

The solution appears to be to replace all the "\" with "/" in the path that you're passing in. Yeup, that simple. So, say you have a property called "filename" in a nant script, you could pre-process it with:

<property name="target" value="${string::replace(filename, '\', '/')}"/>

Which should give you a filename that MySql can stomach

I previously wrote "hotfrog.co.uk - aka: Reed; stop scraping the web, please!" a little over a month ago.

More recently I discovered Karen Blakeman's blog (worth a read, very interesting). From what she's written, it would seem hotfrog.co.uk was at some point a pretty useful site. Hopefully they'll sort themselves out and get back to being that way.

... does not work. At least in my experience for System.Web it doesn't.

As per Scott Hanselman's blog entry, the patches required to install this are now available, but installing them pushes the version of System.Web up to one that's not yet available on http://referencesource.microsoft.com/

There's a fantastic set of instructions available from Shawn Burke on Configuring Visual Studio to Debug .NET Framework Source Code, the one thing it doesn't mention (but is mentioned in the comments) is that restarting Visual Studio after setting everything up seems to be the magic key for getting the source-downloading and stepping-into going

According to phpclasses.org, metabase_interface.php is a "PHP Database access layer RDBMS independent".

According to my logs for this site, it's a file that spammers/scammers have discovered a vulnerability in. Within the past 48hours I've got just under 100 hits against various guises of this file, none of which exist, showing up in my 404 logs. So much so that they out-number all other 404s for the rest of the month.

I could be wrong about it being something that has had a vulnerability in discovered, but that many attempts to load it when there are no references to it within my site do make me wonder...

The project I'm working on at the moment uses an IHttpHandler to process file uploads and prevent them being loaded entirely into memory. Unfortunately, upgrading to .net 3.5 seems to have broken it.

Every request to the ReadEntityBody method of the ISAPIWorkerRequestInProc (which derives from ISAPIWorkerRequest which derives from HttpWorkerRequest) blocks for 60 seconds and then returns no data. I've not yet had a chance to download the source from Microsoft and drill all the way down during execution, but suspect that will be the next avenue of attack.

I have a project that's built by Visual Studio 2005 (via CC -> nant) and generates an MSI file for a web project. Every once in a while it generates an installer that contains a corrupted CAB file, I have no idea why. Google isn't providing any pay-dirt either.

I'm going to upgrade the build process to VS 2k8 in the hopes that will help make the problem go away. As it only ever happens with 1 of many web project builds, I'm not getting my hopes up :-|

Why QA is Important, from the people behind Fog Creek Copilot. I really couldn't have put it better myself. My only query with the whole entry would be; why on earth don't the staging servers have SSL on them? A self-generated certificate would be sufficient to avoid the hassle of splashing the cash for staging boxes.

The isFiltered() method of the Ext.data.Store class returns "undefined" when no filter is set or one has been set and cleared, rather than False. Either a duff copy in the Coolite assembly, or what smells like a bug in the implementation. Unless of course a return type of Boolean is now a tri-state of true, false and undefined?

If you trundle along to the Wikipedia page on Back to Black, there are links to listen to (what I assume are fair-use) snippets of two tracks. The problem is; you can't actually listen to them unless you install an Ogg Vorbis codec/player. This is because they are blah, blah, blah, "completely free, open, and unpatented", blah, blah, blah. So because of that, Wikipedia offers a piss poor user experience.

Contrast that to the amazon.co.uk page for Back to Black. I can listen to samples without downloading anything. That's much better.

Wikipedia, please get off your high-"Must be open, rah rah rah"-horse and sort it out. You get lots of donations, more than enough to pay fees for using MP3s or similar if needs be, I'm sure.

I have an ExtJs store that causes an error to raise when its rejectChanges() method is called. It looks like (from stepping through) that the rowIndex that the underlying ExtJs code is trying to hit is out of bounds. Why, I'm not sure. The closest search result I find took me to Commit/Reject changes in EditorGrid from the ExtJs forums, which was *not* helpful :(

I haven't worked out why it worked (as my code *does* already clear the filter earlier in the execution path), but, adding:

store.clearFilter(true);

Immediately before the call to rejectChanges() works a treat. Go figure!

Has anyone found a good way to do this? Or, indeed, is there a trick I'm missing from Coolite? There doesn't appear to be a "Coolite." namespace declared in the same way there's an "Ext" namespace declared/provided when the components are used on a page.

What I want to be able to do is write arbitrary client side javascript (event handlers and suchlike) inside a script block rather than inside an attribute of the server-side tag. The different ways I've discovered are:

Inside tag attributes
This is the tidiest way of writing the code as you get "nice" shortcut referencing of the server-side components like:

  <ext:GridPanel Title="My Grid of Items" ID="myGrid" runat="server" StoreID="itemStore" >
      <ColumnModel>
          <Columns>
              <ext:Column Header="Id" DataIndex="ItemId"/>
              <ext:Column Header="Name" DataIndex="ItemName">
              </ext:Column>
          </Columns>
      </ColumnModel>
      <SelectionModel>
          <ext:RowSelectionModel runat="server" SingleSelect="true">
              <Listeners>
                  <RowSelect Handler=
                    "#{modifyItemButton}.enable(); 
                    #{deleteItemButton}.enable();" />
                  <RowDeselect Handler=
                    "if (!#{myGrid}.hasSelection()) 
                    {
                      #{modifyItemButton}.disable(); 
                      #{deleteItemButton}.disable();
                    }" />
                  <Show Handler=
                    "if (!#{myGrid}.hasSelection()) 
                    {
                      #{modifyItemButton}.disable(); 
                      #{deleteItemButton}.disable();
                    }" />
                  <SelectionChange Handler=
                    "if (!#{myGrid}.hasSelection()) 
                    {
                      #{modifyItemButton}.disable(); 
                      #{deleteItemButton}.disable();
                    }" />
              </Listeners>
          </ext:RowSelectionModel>
      </SelectionModel>
      <Buttons>
          <ext:Button Text="Refresh" runat="server" ID="refreshGridButton">
              <Listeners>
                  <Click Fn="refreshGridButton_Click" />
              </Listeners>
          </ext:Button>
          <ext:Button Text="New" runat="server" ID="createItemButton">
              <Listeners>
                  <Click Fn="createItemButton_Click" />
              </Listeners>
          </ext:Button>
          <ext:Button Text="Delete" runat="server" ID="deleteItemButton" Disabled="true">
              <Listeners>
                  <Click Fn="deleteItemButton_Click" />
              </Listeners>
          </ext:Button>
          <ext:Button Text="Modify" runat="server" ID="modifyItemButton" Disabled="true">
              <Listeners>
                  <Click Fn="modifyItemButton_Click" />
              </Listeners>
          </ext:Button>
      </Buttons>
  </ext:GridPanel>

Which shows using the "#" shortcut to resolve client-side control names. This doesn't actually do anything client-side, but instead is processed by Coolite as part of the controls rendering and converted into fully qualified names. It also makes for code that's quite difficult to work on as you get no Intellisense/Syntax highlighting, etc, inside the attribute.

<%=ServerControl.ClientID=> jiggery-pokery

The other option is to have a block of code inside your javascript that says something like:

function getMyGrid() { return <%=myGrid.ClientID%>; }

which causes the ASP.net rendering engine to emit the relevant reference. This, rather than using "document.getElementById" works for Coolite created ExtJs components as they're javascript objects that render markup, rather than markup elements with associated javascript. Or at least, that's how it appears from my perspective (Your viewpoint may vary).

The code snippet above seems to generally upset the crap out of the Javascript parsing engine in Visual Studio 2k8 and means you get an irritating yellow warning in the Error List. Changing it to be the following code (yes, eval bad, etc,..) removes the warning:

function getMyGrid() { return eval('<%=myGrid.ClientID%>'); }

What I want

Something similar to "document.getElementById" or ASP.net AJAX's $get/$find pair but for Coolite. It may already be in the Coolite code, but if not, it's going to get written (if at all possible) by me very soon. So, I'll be able to write:

var myGrid = Coolite.getComponent('myGrid');
if (myGrid.hasSelection())
{
// Do something here
}

Without having to worry about the fact that 'myGrid' is stuck in several ASP.net naming containers and is thus actually called ctl00_mainArea_subArea_ctl02_myGrid, or something equally obscure.