I've been experimenting with the idea of using System.Reflection.Emit to generate code from interfaces.  If you're not familiar with this namespace, it contains classes to generate compiled assemblies programmatically.   Regex uses this when compiling a regular expression for faster execution.  Instead of parsing the expression each time, it generates on-the-fly a class that can be used to execute the expression.  This namespace is also used by Mock Type frameworks such as RhinoMocks and TypeMock.  Given a base class or interface, these generate on-the-fly a class that can mimic the base enough to use when unit testing.  I'm sure there are other places this is used, but suffice it to say this is one of those obscure corners of the framework that us Morts rarely dig into.  So it's not surprising that I would run into an obscure error that stumped even Google.

I religiously studied the MSDN examples and wrote code to let me do something like this:

ICustomer concreteType = CodeGenerator<ICustomer>.GetInstance();

You can see how freaking awesome this could be for component development- I get, at runtime, a class that implements my interface, but I don't have to wire up goo like INotifyPropertyChanged, IDataError, property getter/setters, etc.   Depending on how my tinkering goes, more on the awesomeness later.  The error I was getting whenever I called typeBuilder.CreateType() was:

System.TypeLoadException: Method 'get_Id' in type 'Customer' from assembly 'TypeAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation

Except I WAS implementing 'get_Id'.  I copied the code to do it straight from MSDN! See:

MethodAttributes getSetAttributes = MethodAttributes.Public |
MethodAttributes.SpecialName |
MethodAttributes.HideBySig;
var getMethodBuilder = typeBuilder.DefineMethod("get_" + propertyOnInterface.Name,
                                                getSetAttributes,
                                               propertyOnInterface.PropertyType,
                                               Type.EmptyTypes);

ILGenerator getMethodIl = getMethodBuilder.GetILGenerator();
getMethodIl.Emit(OpCodes.Ldarg_0);
getMethodIl.Emit(OpCodes.Ldfld, fieldBuilder);
getMethodIl.Emit(OpCodes.Ret);

propBuilder.SetGetMethod(getMethodBuilder);

Much googling turned up only a few unrelated posts.  After testing, I discovered that removing a call to 'AddInterfaceImplementation' fixed the issue- though the resulting class no longer implemented my interface.  Clearly the interface was generating some sort of code.  Some more digging, and I figured out the solution:

MethodAttributes getSetAttributes = MethodAttributes.Public |
MethodAttributes.SpecialName |
MethodAttributes.HideBySig;| MethodAttributes.Virtual;

I could be flawed in my understanding here, but apparently, when adding an interface, .NET treats property get and set accessors sort of like abstract methods.  The code I was generating did implement 'get_Id', but did not mark it as overriding the interface's definition.  So, when creating the type, there was the interfaces' unfinished implementation of 'get_Id', and my completely unrelated 'get_Id'. 

So anyway, hopefully this post will make it into Google and help some other poor guy who, late one night, finds themselves turning over parts of the framework better left alone.

Here's a fun Alt-Tab Shortcut that lets you switch apps without leaving the comfort of your mouse.  Just download, place in Startup, and run.  When it's running, you can switch apps by holding down the left mouse button and clicking the right.   Like most productivity apps, I may find myself forgetting it's there and not using it after the novelty wears off, but I guess we'll see.

Incidentally, the standalone exe is a feature of AutoHotKeys, which is one of those said productivity apps that I forget about and rarely use.  The idea is pretty neat though. It's a little scripting language for automating those little repetitive tasks that we all hate.  The end result is apparently a standalone exe that "just works", no installer required.

One of the challenges of being a contract software developer is that we often work remotely on a clients' network via VPN.  Each client has their own VPN client, Source Control, and development environments.  In many cases, development platforms just aren't made with this in mind.  It's only as of VS 2005 that you can even switch Source Control Providers easily! If you've ever had to connect to Microsoft SourceSafe over VPN, you know it's still not designed with remote work in mind.  It relies on a network file share, which can be problematic over VPN.  It does ship with a WebService based solution, but this may not be feasible for the client to install in all cases.

The Problem

When connecting over VPN, the main problem is that there is no option to specify the network user to connect with.  For example, you may log in to the clients' VPN, but still attempt to access resources using your machine's local account.  When doing things like mapping drives, it's easy to supply an alternate username and password.  However, with SourceSafe, there is no option to supply network credentials when connecting (which are totally different from the SourceSafe credentials).

The Solution

Enter the Windows runas command.  This command lets you run any application as though it were a different user.  In this case, you want to run Visual Studio as though you were that network user.  To set this up:

• Create an empty text file named "RunVisualStudioAs[DomainUserName].bat"
• Edit and Add the following:
• runas /netonly /user:[Domain]\[User] "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"
• Save.

Then, when working on the project, just launch VS using the batch file.  You will be prompted for a password each time, since runas does not allow entering a password in the commandline for obvious security reasons.  But there are 3rd party runas replacements which can help you get around this.

One other word of caution:  Due to the chatty nature of Windows file sharing, this will still be very slow over a remote connection.  Turning off Anti-Virus helps a little, and there are some additional speed tips here. It's definitely not the ideal solution, but it can be done!

For one of our clients, I've been working on converting printed forms into web forms, and in the process have been dealing with a lot of tables that need to fit within a fixed width.  These tables are in a FormView in a User Control, which are then placed on webpages as needed.  I was finding that Visual Studio 2008's design mode was happy enough to accept my fixed-width columns and tables settings in my CSS stylesheet when working on the User Control, but once that User Control is placed on an actual page the fixed-width settings are no longer respected in both design mode and in debug mode displayed through a browser.  What to do?  After much frustration I found the embarrasingly simple answer: I wasn't putting "px" at the end of pixel measurements for table/column widths.  For whatever reason the Visual Studio 2008 FormView designer was content without the "px" but nothing else was.  In my rush to get things working I was leaving off the "px" figuring that I could go back later and add them on after the fact.  So lesson learned: be standards compliant, even if your development tool of choice lets you get away with not being standards compliant.

Still on the topic of fixed-width tables and columns, have you ever wanted to figure out exactly how many pixels wide/tall something is on a webpage, be it a table row, table column, header graphic, etc.?  Enter Pixel Ruler--a free app that displays a rotatable ruler on your screen and even tracks your mouse cursor and keeps a running measurement of how many pixels away you are from the zero mark on the ruler (in one dimension of course--it doesn't do diagonal measurements).  This app will save me countless hours of eyeballing and hoping for the best, instead providing me with precise measurements to the pixel.