Recently in .net Category

If you encounter the error message "Failed to access IIS metabase" when making a request to a newly created ASP.net virtual directory under IIS, or even one that was created a whle ago on a machine that has had Visual Studio added/removed/upgraded/repaired, the solution is generally to go to WINDOWS_DIRECTORY\Microsoft.Net\Framework\FRAMEWORK_VERSION in a command prompt and run "aspnet_regiis -i"

Discovered at: http://cgaskell.wordpress.com/2006/11/22/failed-to-access-iis-metabase/

I've been encountering a strange error with extJs (when using Coolite) that I think may be IE8 specific, but I haven't been able to prove it yet.

When I use the <ext:Grid> and set the ClicksToEdit to "1", rather than the default of 2, if I click through the editable fields in the grid too quickly I receive an "unspecified error" on a call to getClientRects. Very odd. Also, the editable textboxes for the bottom-most (of the two rows in the grid) row won't render/become editable unless the grid has been sorted (at least once). Even more odd.

Whilst hunting for a way to do this I found this sample/example at agrinei.com. [via: Joteke's aspadvice.com blog]

For the avoidance of doubt (and hopefully so it'll make anyone else who wonders about this have an easier time searching), the insertRecord method on the Coolite implementation of the extJs grid is added by Coolite.

Be prepared to see more like this :-S

I can heartily recommend the Coolite framework for this, rather than battling with Javascript syntax. It's currently at v0.6 (c'mon, hurry up and release v0.7!) and thus is missing some functionality that I'd really quite like to use but it is pretty damn good. The big win for me is the fact that you get to describe your extJs "stuff" using markup that's validated by Visual Studio for you. Big. Win.

Follow coolite on twitter. (That's how I'm watching for v0.7!)

It would appear that in a couple of comments I posted on the IE blog, I've come across as a Microsoft fanboy! To summarise, the point I was responding to was one that basically said:

All other browsers have a public bug tracking system, so why doesn't IE?

That point is simply not true. Opera has a bug reporting page, Safari has a bug reporting page and Firefox does have a public bug tracking system. Thusly, all other browsers do not have public bug tracking systems. Yes, Webkit (the rendering engine that underlies Safari) does have a public bug tracking system (which I may have to acronym as PBTS before my fingers drop off!) but the rendering engine isn't the only part of a browser by any stretch of the imagination.

My main thrust was that the statement I paraphrased above is simply untrue. Many people have (and rightly so) accused Microsoft of using a FUD strategy, and false statements like that one are of a very similar ilk. Oh - and a re-reading of my comment would highlight the fact that I didn't state that I disagreed with the need for a public bug tracking system for IE, but that's a whole different kettle of fish.

Now, onto the "fanboy" accusation. Baseless. Utterly baseless. Yes, I use Microsoft technologies, but I'd be equally happy (well, not so much because the toolset simply isn't as grokkable as Visual Studio, even with all its foibles) to use JSP rather than ASP.net, after all, it's really all just syntax. A semicolon here, a curly bracket there, or, god forbid, a With/EndWith ;)

B. Cortez said:

Well, if you bothered to look into it even on a superficial level, you'd see that a Bugzilla system has the ability to search, as well as "sign-up" to be notified of changes to the bug report (via email notifications).  Also, you can, amazingly, VOTE for a bug.  This is the weight given to the bug by, imagine this, CONCERNED CUSTOMERS.

Bugzilla. Yes, I've used it before. The company I worked for until the end of November implemented it to replace Rational ClearQuest, what a breath of fresh air that was! The company I work for now uses a custom built defect tracking system, but I'm trying to sell them on Bugzilla. Nowhere did I say that I didn't know how Bugzilla worked, or what it does. In fact, I quite like it. (I especially like the Mozilla artwork that loads whilst searching and chomps bugs ;)

Also, "If you bothered to look, or be involved in cross-browser web development in any form", how does anyone know that I'm not? document.getElementById makes me squee, document.all makes me want to retch. The inconsistencies in the box model and having to use big dirty ClearFix-esque hacks make me angry.

Remember, don't assume, it'll make an "ASS out of U and", well that's where I break from the traditional version of the saying, because assuming only makes an ass out of one person. The person making the assumption.

A while ago I posted an entry with links to a couple of blog entries from other people relating to ASP.net Viewstate. The blogger who created the first entry has a new related posting titled Truly Understanding Viewstate, the Comment Index which basically points everyone in the direction of a document someone else has prepared that aggregates and documents the 250+ (yes, 250+!!) comments that ended up being attached to the original entry. What a bloody fantastic resource. It's things like that which make me realise just how useful a resource blogs are. 10 or even 5 years ago, this level of information simply was not available other than in the "dead tree" format and that was invariably based on what a book author/publishers opinion of what needed covering was.

It's things like this which make me wish that there was a viable micro-payment model in existence as I'd happily chuck a little bit of money in the direction of both of those people by way of thanking them for providing such useful content.

The blogger who originally posted the Viewstate entry also has a series dedicated to ASP.net and Dynamic Controls which is also well worth a read for anyone who's dabbling with ASP.net and controls. Even if you're lucky enough to not have to deal with anything but controls declared in the .aspx file, it's well worth a read to deepen your overall understanding of the way ASP.net works.

Andrew Rea has a pretty good posting on his blog describing a funky looking group box custom control for WinForms. The UI examples he's shown kind of remind me of dividers in a ring binder, which might be useful in some user interfaces where that kind of metaphor would be appropriate.

Whilst undoubtedly they look very smart, it does remind me how much more complex it is to design controls for WinForms than ASP.net, a similar construct in the latter would be a smattering of CSS and a transparent image or three. I know that the corners would be a bugger, but, code-wise it'd be a damn sight easier to read. (Not that I'm saying that the code is badly written!)

Bring on WPF I say ;)

Take a look at Mark: Ramblings from a programmer, if you dare. Whilst some of the points he makes are good, for example that Visual Studio doesn't inherently encourage programming best practice, i.e. the separation of presentation, business and data layers, a lot of his other posts are purely rants about the fact that VB6 and VFP (Visual Basic 6 and Visual FoxPro for those who tire of acronym soup!) are no longer being produced. Ironically, VB6 does little or nothing to encourage the separation of presentation, business and data layers, so any bleating about the "good old days" do fall on deaf ears somewhat.

Having taken a mooch through his blog, I came across a post surrounding designing custom controls. Or at least, his opinions regarding VS's shortcomings. I thought it'd be worthwhile to go through each point in turn and analyse/debunk them:

1. Sub-classing a control doesn't cause the new control to inherit any design-time attributes, specifically Toolbox icon.
2. Altering a property in the child class causes the property value to show in bold in the property page for the control when it's placed on a form. Oh, and the fact that changing the value of a property in the class thusly doesn't propogate through to any derived application.

So, in response;

1. Why's this a bad thing? This might just be down to a matter of opinion, but surely the name, icon and other odds and ends should be down to the developer. How about if you inherit from System.Windows.Forms.Control,... what icon should be used then? Or one of the abstract base clases like S.W.F.ListControl?
   As a Control developer, get off your arse and choose an icon, rather than expecting Visual Studio to do everything for you.
   
2. Altering a property in a way that causes the property value to show in bold means that you've done it the wrong way. The author even goes as far as mentioning the System.ComponentModel.DefaultValueAttribute and then whines that using this is a "work around" to a "bug" in Visual Studio.
   Consider for a moment if the Visual Studio designer determined what the default property value was based on the return value for the property get routine, this routine could go off and query the Registry / contact a web service / choose the Nth font installed based on the number of elapsed seconds in this specific minute, in short - the return value could be entirely nondeterministic and even long running. By decorating the property with an Attribute, any Designer tool can determine immediately and deterministically what the default value for the property is. This also results in NO code being generated within the application using the control and thus any change to the default value being propogated upon recompilation of the Control.

I'm not taking this as an excuse to bash a Microsoft basher, don't get me wrong, Visual Studio bugs the crap out of me at times too, but someone with such a deep and broad level of experience should really at least make sure they understand what they're talking about, and more importantly, how to use the tools at their disposal, before they chuck an "it's all crap because it's not VFP/VB6" bitch-fest.

Property Attribute Example
Just to highlight why the attribute based default value for a property is better, consider the following code:

public class ControlWithProperties : Control
{
    private Font _font;

    [DefaultValue("Segoe UI")]
    public override Font Font
    {
        get { return _font; }
        set { _font = value; }
    }

    public Font OtherFont
    {
        get
        {
            if (_font == null)
            {
                if (DateTime.Now.Second < 30)
                {
                    _font = new Font("Century Gothic", 20);
                }
                else
                {
                    _font = new Font("Comic Sans MS", 20);
                }
            }
            return _font;
        }
        set
        {
            _font = value;
        }
    }
}

With the first example property, any Visual Designer (or indeed parser, decompiler, etc) can immediately determine what value to show in a property grid, but with the second (albeit contrived) example, all bets are off. For describing the attributes of something, attributes are definately the way to go.

One of the beauties of the ASP.net system is the way you can declaratively describe controls that sit on the page, and also the contents of collections that they contain as properties, as shown as an example snippet below:

<asp:DataGrid ID="ADataGrid" runat="server">
    <Columns>
        <asp:ButtonColumn ButtonType="PushButton" Text="I'm a button!">
            <ItemStyle CssClass="ButtonItem" />
        </asp:ButtonColumn>
    </Columns>
</asp:DataGrid>

Writing the code to gain page designer support for this is very simple and doesn't actually involve writing any code! The following code demonstrates a basic (as it doesn't actually do anything!) Web Control that provides designer support for describing the contents of one of its properties declaratively:

[ParseChildren(true)]
[PersistChildren(true)]
[ToolboxData("<{0}:CustomControlUno runat=server></{0}:CustomControlUno>")]
public class CustomControlUno : WebControl, INamingContainer
{
    private Control1ChildrenCollection _children;

    [PersistenceMode(PersistenceMode.InnerProperty)]
    [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
    public Control1ChildrenCollection Children
    {
        get
        {
            if (_children == null)
                _children = new Control1ChildrenCollection();
            return _children;
        }
    }
}

public class Control1ChildrenCollection : List<Control1Child>
{
}

public class Control1Child
{
    private int integerProperty;
    private string stringProperty;

    public string StringProperty
    {
        get { return stringProperty; }
        set { stringProperty = value; }
    }

    public int IntegerProperty
    {
        get { return integerProperty; }
        set { integerProperty = value; }
    }
}

The key is the four attributes, two decorating the class and two decorating the property to be exposed through the markup designer. An example of the markup that could then be written is below:

<Abc:CustomControlUno runat="server" ID="Control1">
    <Children>
        <Abc:Control1Child IntegerProperty="1" StringProperty="Item1" />
        <Abc:Control1Child IntegerProperty="2" StringProperty="Item2" />
    </Children>
</Abc:CustomControlUno>

I couldn't find any better, reusable way to get all the values from a specific column of a datatable, strongly typed than the snippet below:

        internal class DataColumnConverter<T>
        {
            internal T[] GetValuesAsArray(DataTable data, string columnName)
            {
                List<T> values = new List<T>();
                foreach (DataRow r in data.Rows)
                {
                    values.Add((T)r[columnName]);
                }
                return values.ToArray();
            }
        }

Things it's missing:

• Type Cast checking on the type of items in the DataTables' column that's specified
• Checking that the column specified exists
• Handling of a column which contains nullable values (Could <T> be passed as, for example int? to cater for this? maybe! Or perhaps null's could be stripped out...)

ASP.net is much maligned, but if carefully managed, it can be a very useful part of a web developers toolbox for ensuring performance and UX in a web app. A couple of *very* useful links to posts about viewstate below:

- Truly Understanding Viewstate. Quite a long posting, with a lot of comments attached which also have some value. Well, well worth a read.
- Thoughts on the ASP.NET ViewState. More interesting content with a couple of useful/insightful comments.
- Master Page and PreInit. Not exactly entirely related to Viewstate, but it mentions a "trick" for getting access to controls on a page that has a Master Page associated, in the PreInit stage of the page lifecycle, something that otherwise blows a raspberry at the developer.

Web References in Visual Studio are annoying. Yes, they take the pain out of binding to a web service, providing generated code that gives you type-safety. But, and this is a big but, the classes that Visual Studio generates are marked as public rather than internal. If you're writing a library that wraps your web service, this provides any caller of the library with direct access to the web service, not so bad I hear you say as anyone who knows the Url can add it as a Web Reference and code directly against it. The big annoyance is that it makes your libraries interface messy and exposes what's essentially an implementation detail. Imagine for a moment that you have an application where the layers are deployed to separate machines, and also geographically dispersed, using a model similar to the one below.

In this model you'd want to hide the web service as it may not ever be used (and really is an implementation detail!), the lack of an option to define the visibility of the Web Reference makes this impossible without hand editing the generated code.

Related Links
- The bug/feature request logged on MS Connect site. (Marked Closed/WontFix, grr!)
- Programatically adding Web References, I've not looked in too much detail, but maybe it's possible to use this to add an internal web reference?

There are a couple of ways to handle getting at un-exposed methods for the purposes of Unit Testing, as described below. Method 2 is, I believe, pretty similar to the way that the Unit Testing tools in the higher editions of Visual Studio operate, albeit with the ability to automatically regenerate the code. Which do you prefer?

Method 1 – InternalsVisibleTo

Requires adding [assembly: InternalsVisibleTo("CompanyName.xxxxxx.xxxxxx.Test")] to the AssemblyInfo.cs file for the CompanyName.xxxxxx.xxxxxx project, then declaring any required methods/properties as internal rather than private.

Pros

-       Intellisense provided by Visual Studio when writing Unit Tests

-       Immediate Compile Time failures when attempting to build Unit Tests if the interface on class has changed when Unit Tests are compiled

Cons

-       Other classes in the same assembly have access to internal parts of a classes interface.

-       The runtime DLLs contain a "reference" to the Test DLLs (albeit one that doesn’t do anything unless the Test DLLs attempt to reference the runtime DLLs)

 

Method 2 – Reflection (Method Invocation)

Requires using reflection, so for example to call the FacadeManager.Disconnect() method, the following code would be required (can be shortcut)
 

Type t = FacadeManager.Instance.GetType();

MethodInfo Disconnect = t.GetMethod("Disconnect", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);

Object[] Parameters = new Object[]{(object)"Disconnecting for Test _008_DisconnectMethodWorks"};

      Disconnect.Invoke(FacadeManager.Instance, Parameters);

This can be wrapped in a testing support class, a la:

 

class FacadeManagerProxy

{

    private FacadeManager _facadeManagerInstance;

    private Type _t;

    private MethodInfo _disconnect;

    private MethodInfo _connect;

    public FacadeManagerProxy(FacadeManager facadeManagerInstance)

    {

        _facadeManagerInstance = facadeManagerInstance;

        _t = _facadeManagerInstance.GetType();

        _disconnect = _t.GetMethod("Disconnect", BindingFlags.Instance | BindingFlags.NonPublic);

        _connect = _t.GetMethod("Connect", BindingFlags.Instance | BindingFlags.NonPublic);

    }

    public void Disconnect(string reason)

    {

        Object[] Parameters = new Object[] { (object)reason };

 

        _disconnect.Invoke(_facadeManagerInstance , Parameters);

    }

    public void Connect()

    {

        _connect.Invoke(_facadeManagerInstance, null);

    }

}

Jamie Cansdale, developer of TestDriven.NET is currently embroiled in what could be the start of a legal fight with Microsoft, regarding him having extended Microsofts Visual Studio Express products.

Admittedly the EULA (which are allegedly on shaky ground legally anyway, not just Microsofts, but everyones) is a bit vague and just states "thou shalt not work round technical limitations in the software", but given that Microsoft have disabled the Add-In model in the Express editions and Jamie had to use a "hack" to get his product to integrate, surely he must realise that he's violating the "spirit" of the Express editions, if not the EULA to the letter. His hack involved using another extensibility point that's intended for use by things that are not Add-Ins but that cannot be removed as it's an integral part of the development environment.

The question I'd love to see him answer is "by loading into the Express products the way you did, when the standard extensibility points had clearly been disabled, how did you think that this wasn't against the spirit of the product?". That question he's never answered. Ever.

I can quite happily do everying I need to do, Unit Test wise, without using his product, although it would make life easier and I wouldn't object to the price-tag. However, I won't.