A few weeks ago I made some updates to my Regular Expression Assembly Builder that I wrote some time back.  These updates have long been requested by users and I finally carved out some time to get them implemented.

These are the new features in verion 2.0.0.3:

• NEW: Added the ability to assign a description to each regular expression.  These are stored in the RegexDescriptionAttribute class.
• UPD: Rearranged the RegexEditor to accommodate the new description, changing some labels in the process, and tab order.
• UPD: Made the validation textboxes 'public' so their references aren't be continually lost each time the editor is opened in the designer.
• UPD: Updated About box link to point directly to http://blog.devstone.com/aaron.
• UPD: Added the regular expression description to the regular expression grid.

Though perhaps a small update, I hope the changes are found to be useful.

NOTE: The File menu has two 'Save' options: Save Project and Save Release Version.  These were added a few versions ago, but I'd like to clarify their usage.  Save Project will save your .dll (because the application works natively with a .dll as its project).  Save Release Version will create a \Release directory and save your .dll there as well.  However, the Release Version has a few things (like the regular expression descriptions) stripped out.  It's the Release version you'll want to reference in your applications if you plan to distribute the .dll; otherwise, you'll end up with a dependency on RegexAssemblyBuilder.exe and you wouldn't want to distribute that :).  If you source control your .dll, I'd recommend storing both .dll files so you have your project and your release version on hand.

Also, partially due to my migration to dasBlog, I've not gotten around to updating my little downloader application.  Therefore, you can simply download the application directly here.  Let me know if you have any issues with it.

For a history of the application, please check out this post and its links as well.

Suppose you have a table (tblDemo) and a view (vwDemo) over that table that joins tblDemo to another table to retrieve their results.

The view might resemble the following:

CREATE VIEW vwDemo
AS
SELECT d.*, o.OtherField01, o.OtherField02
FROM tblDemo d
INNER JOIN tblOther o ON d.ID = o.ID

While I've never advocated selecting * from anything, it does have its uses; but it turns out there's potentially a nasty gotcha.  Personally, I like to err on the side of higher specificity, though that usually requires a bit more manual tweaking as time goes on.

What happens if the schema of tblDemo changes?  Well, if you don't update or recreate your view, you may very well get some unexpected side effects.

For instance, if a new field were added to tblDemo (e.g., ALTER TABLE tblDemo ADD NewField int), the view, when inspected in SQL shows the following:

SELECT d.ID, d.Field01, d.Field02, d.Field03, d.NewField AS OtherField01, o.OtherField01 AS OtherField02, o.OtherField02
FROM tblDemo d
INNER JOIN tblOther o ON d.ID = o.ID

Notice that the 'NewField' got aliased with the field name at the new fields position! That field, in turn, received the next field's alias, and so on. Understandably, this can have some very negative side effects in your applications.

For this reason I would strongly recommend AGAINST using SELECT * in a view in SQL Server.  Of course, if your view does nothing but SELECT * on a single table or the '*' is the last part of the SELECT clause (such as SELECT o.OtherField01, o.OtherField02, d.* FROM ...) then you circumvent the issue.  When used in conjunction with other columns, however, there are indeed repercussions.

I don't know that this is a bug in SQL Server, though it may appear to be at first.  I'm not a SQL Server guru (though I'm exceptionally dangerous with it :)), but I suspect that upon building the view, SQL catalogs all of the fields in a pseudo-table.  Changing the schema thereof, without updating the view causes a misalignment between the new schema and the pseudo-table that was build previously.

Can anyone confirm this or elaborate on the behavior?

I had a lot of fun preparing for and presenting on Silverlight 2 at the Utah .NET User Group the other night.  It was a great evening.  Thanks to all that come out to participate and help bolster the .NET development community. :)

Alright, this has been a downright stumper and I'm currently at a loss.  For this reason, therefore, I'm opening up to the community to see if anyone out there has any recommendations to this dilemma.

The issue revolves around running a 32-bit application on a 64-bit version of Windows and the application needs to pull values from the Registry.  One thing that 64-bit Windows will do, to help achieve compatibility with 32-bit applications by transparency, is remap (redirect) registry calls.  In other words, when I request "HKLM\SOFTWARE\Test Company\Application Name\Key Name" it actually redirects this to "HKLM\SOFTWARE\Wow6432Node\Test Company\Application Name\Key Name" for storage and retrieval.  So far so good.

Well, I have an old 32-bit application written in VB 6.0 that writes a value to the registry that my .NET application must read.  For argument sake, let's say that the value is ultimately written to the HKLM\SOFTWARE\Wow6432Node\Company\Application\Settings key with a name of Value01.  This is precisely what I'd expect.  However, when I attempt to read this value in my .NET application (I'm using VS 2008, .NET 3.5) I'm getting erratic results.

This is what I have:

My application is explicitly compiled as a 32-bit application.  To do this, I've set the Platform target project property to x86.  I've also confirmed this using the CorFlags.exe, even going to far as using the /32BIT+ switch to ensure the setting.

I have a few varieties of code that seem like they should successfully read the value:

Take 01:

private static string getValue01() {
   return getCompanySetting("Application", "Settings", "Value01", "Not found");
}

private static string getCompanySetting(string appName, string section, string key, string defaultValue) {
   string subKey = string.Format(@"SOFTWARE\Company\{0}\{1}", appName, section);
   return getRegValue(subKey, key, defaultValue);
}

private static string getRegValue(string subKey, string key, string defaultValue) {
   RegistryKey key = Registry.LocalMachine.OpenSubKey(subKey);
   if ( null != key ) {
      object val = key.GetValue(key);
      return ( string.IsNullOrEmpty(val) ? string.Empty : val.ToString();
   }
   else {
      return new Win32Exception(Marshal.GetLastWin32Error()).Message;
   }
}

Take 02:  This is almost the same except that I use the WinAPI directly to read the value rather than the managed objects.

private static string getValue01() {
   return getCompanySetting("Application", "Settings", "Value01", "Not found");
}

private static string getCompanySetting(string appName, string section, string key, string defaultValue) {
   FieldInfo fi = Registry.LocalMachine.GetType().GetFields(BindingFlags.NonPublic | BindingFlags.Instance)[0];
   SafeHandle hKey = ( SafeHandle )fi.GetValue(Registry.LocalMachine);
   string subKey = string.Format(@"SOFTWARE\Company\{0}\{1}", appName, section);
   return getRegValue(hKey, subKey, key, defaultValue);
}

private static string getRegValue(SafeHandle hKey, string lpszSubKey, string szKey, string szDefaultValue) {
   StringBuilder szBuffer = new StringBuilder(255);
   uint lBufferSize = ( uint )szBuffer.Capacity;

   int lResult;
   IntPtr phkResult;
   uint lpType;

   lResult = WinApi.RegOpenKeyEx(hKey, lpszSubKey, 0, 1, out phkResult);
   if ( WinApi.ERROR_SUCCESS != lResult )
      return new Win32Exception(Marshal.GetLastWin32Error()).Message;

   lResult = WinApi.RegQueryValueEx(phkResult, szKey, 0, out lpType, szBuffer, ref lBufferSize);
   WinApi.RegCloseKey(phkResult);

   return ( WinApi.ERROR_SUCCESS == lResult )
               ? szBuffer.ToString()
               : szDefault;
}

internal static class WinApi {
   internal const int ERROR_SUCCESS = 0;
   internal const uint KEY_WOW64_64KEY = 0x0100;
   internal const uint KEY_WOW64_32KEY = 0x0200;

   [DllImport("advapi32.dll", CharSet = CharSet.Unicode, EntryPoint = "RegOpenKeyEx")]
   internal static extern int RegOpenKeyEx(SafeHandle hKey, string subKey, uint options, uint sam, out IntPtr phkResult);

   [DllImport("advapi32.dll", CharSet = CharSet.Unicode, EntryPoint = "RegQueryValueExW", SetLastError = true)]
   internal static extern int RegQueryValueEx(IntPtr hKey, string lpValueName, int lpReserved, out uint lpType, StringBuilder lpData, ref uint lpcbData);
 
   [DllImport("advapi32.dll", SetLastError = true)]
   internal static extern int RegCloseKey(IntPtr hKey);
}

In both of these cases, the code runs flawlessly when I run it from Visual Studio with the debugger attached (e.g., F5).  However (and here's the rub) it fails to retrieve the value when I run it directly within Windows or in VS without the debugger (e.g., CTRL+F5).

In all my investigations, it appears that the application IS indeed a 32-bit image (Process Explorer confirms it), but it will simply not redirect to the \Wow6432Node unless it's running with the debugger attached.

Any thoughts of how to address it?  It's driving me nuts.