I've had an issue on two computers (my primary development machine and a virtual pc dev box) which I was finally able to solve today after many hours of frustrated searching and experimenting.  Interestingly, this issue only affected my two machines, but not those of a co-worker.  What was more peculiar was that I have higher privileges in TFS.  The issue revolved around getting the Team Foundation Server Team Explorer 2008 to recognize our automated builds.

Within Visual Studio 2008's Team Explorer pane I am able to browse all work items, documents, reports, etc, but not builds.  In fact, the node shows up with a red 'X' icon and is mislabeled 'Build' rather than the correct 'Builds'.

I attempted to fix it by uninstalling / reinstalling the TFS 2008 Power Tools (July Release), repairing my VS2008 installation, disabling my firewall, disabling my antivirus.  I tried digging into various configuration files and renaming / deleting my cache folder to no avail.

Ultimately, to fix the issue I had to resort to resetting my Visual Studio settings to their factory settings.  To do this, I did the following:

1. Renamed/Deleted by TFS Cache folder.  On my Vista machine it's found in (C:\Users\[USERNAME]\AppData\Local\Microsoft\Team Foundation\2.0).
2. Reset Visual Studio 2008 settings by typing devenv /resetuserdata from the command line.

I finally gave in (for better or for worse) and signed up on facebook.com this past weekend.  I've always had an aversion to such social networking sites for one reason or another.  In fact, facebook.com and myspace.com have long been blocked on my firewall at home until just recently.  I may go back to block myspace.com, however; pretty much everything I've seen on it has been annoying, sleasy, trashy, and not worth my time - basically stuff I didn't want on my computer in the first place.

Now I don't know all the specifics about facebook.com , but I've had a great time on it in the past few days reestablishing connections with friends from my youth in New Mexico.  I've made contact with some people that I've not been able to find until now, which is very exciting.

I realize that I'm a late bloomer of a sort with regards to social networking, but such is the way of things I suppose.  Among other things, I've simply not had time for it.  I still don't have time for it, but I may make some for it, we'll see how it goes.

If you on facebook.com and you know me, drop me a line!

I was putting together a small application today that presents data in a TextBox.  Now while this isn't too uncommon :), the text gets added to the TextBox a line at a time via the TextBox's .AppendText() method.  I needed to do this repeatedly and in succession.  As it turns out, an unwelcome side effect of AppendText is that it scrolls the TextBox as the text is appended.  This resulted in the TextBox getting cleared and then 'wiping' down as the text was added.  Not only was this visually unappealing, but I wanted the insertion point to stay at the top of the contents.

To my knowledge, which is quite flawed and limited, there's not a built-in mechanism in .NET that provides this functionality.  Sure, I could override the TextBox control and manage the WndProc method and/or use SetStyle to make the control user drawn.  But I didn't want to do that.  Well, accomplishing this is quite easy.

There are a few ways we can do it:

1. Use the LockWindowUpdate() API function.
2. Use SendMessage() API function with the WM_SETREDRAW message.

LockWindowUpdate() is slick and arguably easier to use, but it's intended purpose isn't to suppress the redrawing of controls in this manner.  Plus, you can only have one window locked at a time.  So I threw that one out.

I wrapped the logic to lock and unlock the redrawing of the control in an IDisposable object so I wouldn't have to worry about remembering to clean up after myself.  My class is as follows:

public class LockVisualUpdate : IDisposable {
   public LockVisualUpdate(IWin32Window control) {
      _hWnd = control.Handle;
      SendMessage(control.Handle, WM_SETREDRAW, 0, 0);
   }

   private readonly IntPtr _hWnd;
   private const intWM_SETREDRAW = 0x000B;

   [DllImport("user32.dll")]
   private static extern bool SendMessage(IntPtr hWnd, int msg, int wParam, int lParam);

   [DllImport("user32.dll")]
   private static extern bool InvalidateRect(IntPtr hWnd, IntPtr lpRect, bool bErase);

   public void Dispose() {
      SendMessage(_hWnd, WM_SETREDRAW, 1, 0);
      InvalidateRect(_hWnd, IntPtr.Zero, false);
   }
}

Really simple to use.  To consume it, I simply have to do the following:

using ( new LockVisualUpdate(textBox1) ) {
   textBox1.AppendText(...);
   // ...repeated as often as necessary to populate the control

   // when finished, position the insertion point to the top of the control
   textBox1.SelectionStart = 0;
   textBox1.ScrollToCaret();
}

I was experiencing a most perplexing issue yesterday and the day prior that I *finally* resolved late last night.  In essence, I have a Windows Service that I wrote that hosts an adapted Cassini server which, in turn, hosts an ASP.NET website product running on the client's computer.  The issue was the classic case of 'it works on my machine'.

I could install my service, configure it, and run an ASP.NET website on my computer.  It was a beautiful and exciting thing to witness.  When I went to execute it on another computer, however, the service would start up perfectly but when I made the first request to the website the service would crash (immediately stop) and log an error to the system's Application event log.  The error was a FileNotFoundException.

After troubleshooting the obvious stuff for a bit (folder permissions (the Service runs as NETWORK SERVICE), executables in the proper places, comparing systems, etc), I resorted to more drastic means. :)  Actually, this is technique I frequently employ when troubleshooting issues loading assemblies.

You can troubleshoot Fusion binding issues by simply setting up some registry keys on the machine in question.  Fusion, in short, is the name given by Microsoft for their assembly loading and binding technology in .NET.  Because I don't have the .NET SDK or Visual Studio on the target machine in question, I had to set it up manually.  I added the following registry keys:

HKLM\SOFTWARE\Microsoft\Fusion\LogPath (string) with value pointing to my desired output folder (C:\(TEMP)\FusionLog).
HKLM\SOFTWARE\Microsoft\Fusion\LogFailures (DWORD) with a value of 1.

I restarted the service and made another web request to witness the failure for the umpteenth time.  Sure enough I got some output in my FusionLog folder:

*** Assembly Binder Log Entry  (6/13/2008 @ 9:18:40 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  C:\Program Files\Devstone\WebHostSvc\WebHostSvc.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = NT AUTHORITY\NETWORK SERVICE
LOG: DisplayName = WebHostSvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxx
 (Fully-specified)
LOG: Appbase = file:///C:/Documents and Settings/All Users/Application Data/Devstone/Web/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = f9861834
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Documents and Settings\All Users\Application Data\Devstone\Web\web.config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: WebHostSvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxx
LOG: GAC Lookup was unsuccessful.
ERR: No codebases found to download from.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).

The thing that immeidately stood out was the fact that the Initial PrivatePath, Dynamic Base, and Cache Base were all NULL.  On my development machine these all referenced the /Web/bin folder.  Why wasn't it looking in the \bin folder?

At this point I began debugging the service, actually stepping into the .NET Framework code itself to see if I could figure out the issue.  Delving into the HttpRuntime.cs file I could see that the \bin folder gets appended to the app domain's private paths in the InitFusion() method, just as I had expected.  However, somehow the code wasn't getting that far.  Unfortunately, I couldn't step through some of the code leading up to this point so it was difficult to see exactly why it wasn't getting here.  Actually, in retrospect, I should have looked at the code a little longer - the answer was right in front of me.

I noticed from the fusion log that it was performing a GAC Lookup for the assembly.  Now the assembly isn't GAC-registered on my development machine but I was at my wit's end with the issue.  So I GAC'd it:

gacutil /i WebHostSvc.exe

Immediately upon the next request I got the error I was looking for in the browser:

The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files'.

Aha!  The one thing I didn't check but should have before.  Granting NETWORK SERVICE rights to that folder fixed the problem straight away.

I then removed it from the GAC and removed the Temporary ASP.NET Files that were created, restarted the service, and ran it again to verify that it was running properly.

At this point I went back to the source code and sure enough I saw the line I was looking for.  When initializing, it invokes a method called SetUpCodegenDirectory (which maps to the Temporary ASP.NET Files folder).  This method ensures that the caller has write access to it.

So the moral of the story: make sure that the user account that you're using for ASP.NET has write access to the Temporary ASP.NET Files folder and you'll be a much happier developer.

Almost immediately following yesterday's post I got to thinking about supporting static classes / methods.  I see static classes all the time where the class represents a set of related-but-operationally-distinct methods, often utilities.  The post yesterday really had two aspects about it: 1) the retrieval / extraction and the hosting of an assembly embedded as a resource within another assembly and 2) the creation of a proxy type by wrapping the logic surrounding using Reflection to dig into the guts of the referenced object in a base class.

The ante is raised (only slightly) when dealing with static objects.  Static objects have no instance methods and therefore have no inheritance support and no constructors (the static .ctor is really a type initializer and it's quite the same thing).  Our simple example yesterday defines an abstract base class (ProxyClassBase) that encapsulates the logic for creating the proxy instance and invoking the methods within it.

If we were to mimic the structure of the reference object (the object from the extracted assembly) in our proxy class we would be unable to inherit ProxyClassBase because our proxy would be static.  Allow me to flesh out an example illustrating this:

Example 01: Static Proxy

For this to work, I'd have to create a new class.  Let's name it StaticProxyClass.  This class would, in large measure, be quite similar to the ProxyClassBase base type we defined yesterday with a few distinctions:  1) we wouldn't need an Instance (all methods are static) and 2) we can't have a protected .ctor (our proxy would be static and would be unable to inherit the class).

Our type might resemble the following:

namespace HostAsm {

   internal class StaticProxyClass {
      internal StaticProxyClass(string assemblyName, string typeName) {
         _type = AssemblyLoader.GetType(assemblyName, typeName);
      }

      private readonly Type _type;

      internal void InvokePublicVoidMethod(string methodName, object[] parameters) {
         Type[] types = getTypes(parameters);
         MethodInfo method = _type.GetMethod(methodName, BindingFlags.Static | BindingFlags.Public, null, CallingConventions.Standard, types, null);
         method.Invoke(null, parameters);
      }

      private static Type[] getTypes(object[] parameters) {
         Type[] result;
         if ( null == parameters || 0 == parameters.Length )
            result = Type.EmptyTypes;
         else {
            result = new Type[parameters.Length];
            for ( int i = 0; i < parameters.Length; i++ ) {
               result[i] = parameters[i].GetType();
            }
         }
         return result;
      }
   }
  
}

Note that I've included a method (getTypes) that I didn't include in yesterday's example but may well belong in the ProxyClassBase type as well.  This method will assist in resolving overloaded methods (methods with the same name but with differing parameters).

Our static proxy class would effectively wrap an instance of this type and delegate calls to the reference object through it.

namespace HostAsm {

   internal static class CustomStaticClass {
      static CustomStaticClass() {
         _proxy = new StaticProxyClass("EmbeddedAsm.dll", "EmbeddedAsm.CustomStaticClass");
      }

      private static readonly StaticProxyClass _proxy;

      internal static void StaticMethod(string data) {
         _proxy.InvokePublicVoidMethod("StaticMethod", new object[] { data });
      }
   }

}

This is all well and good and it works perfectly well.  There's something missing, however, and a few things bug me about it.

First of all, it bugs me most that we'd end up having to duplicate (in large part) the functionality in one class (ProxyClassBase) in another (StaticProxyClass).  Secondly, we're omitting one major part of the discussion: objects that have both instance methods and static methods.  To me, this is the deal breaker.

To support this and to leverage our ProxyClassBase type even for static methods, I'd do away with the StaticProxyClass and add the methods therein to the ProxyClassBase.  This will necessitate that our proxy type for static types be non-static, but we can pseudo-simulate that by making its .ctor private.  For these, we will have to encapsulate the actual proxy within our proxy type.  In fact, we'd have to take that one more level by creating delegate methods on our proxy class that direct the calls to the base type.  I'd rather do this than muck with the scope of the base class's methods to keep my intentions pure with the base class.

Example 02: Enhancing the ProxyClassBase

The ProxyClassBase will get the functionality we just added to StaticProxyClass as well as a flag indicating whether the wrapped type is a static type.

using System;
using System.Reflection;

namespace HostAsm {

   internal abstract class ProxyClassBase {
      protected ProxyClassBase(string assemblyName, string typeName, bool isStatic) {
         ObjType = AssemblyLoader.GetType(assemblyName, typeName);
         Instance = isStatic ? null : Activator.CreateInstance(ObjType);
      }

      protected Type ObjType { get; private set; }
      protected object Instance { get; private set; }
      protected bool IsStatic { get; private set; }

      protected T InvokePublicMethod<T>(string methodName) {
         MethodInfo method = ObjType.GetMethod(methodName, BindingFlags.Public | BindingFlags.Instance, null, CallingConventions.Standard, Type.EmptyTypes, null);
         return ( T )method.Invoke(Instance, null);
      }

      protected void InvokePublicStaticVoidMethod(string methodName, object[] parameters) {
         Type[] types = getTypes(parameters);
         MethodInfo method = ObjType.GetMethod(methodName, BindingFlags.Public | BindingFlags.Static, null, CallingConventions.Standard, types, null);
         method.Invoke(null, parameters);
      }

      private Type[] getTypes(object[] parameters) {
         Type[] result;
         if ( null == parameters || 0 == parameters.Length )
            result = Type.EmptyTypes;
         else {
            result = new Type[parameters.Length];
            for ( int i = 0; i < parameters.Length; i++ ) {
               result[i] = parameters[i].GetType();
            }
         }
         return result;
      }
   }

}

Then, to finish the puzzle, our proxy class that wraps the static type gets a face lift:

using System;

namespace HostAsm {

   internal class CustomStaticClass : ProxyClassBase {
      private CustomStaticClass()
         : base("EmbeddedAsm.dll", "EmbeddedAsm.CustomStaticClass", true) {
      }

      private static readonly CustomClass2 _proxy = new CustomClass2();

      internal static void StaticMethod(string data) {
         _proxy.invokePublicStaticVoidMethod("StaticMethod", new object[] { data });
      }

      private void invokePublicStaticVoidMethod(string methodName, object[] parameters) {
         base.InvokePublicStaticVoidMethod(methodName, parameters);
      }
   }

}

I've not given this approach a great deal of scrutiny.  At first glance I can see it being somewhat fragile.  If the base class changes you have to proliferate changes to the inheriting types.  Then again, I don't see this base class like this changing much if at all except for new additions.