I ran into a peculiar behavior that Visual Studio 2008 was exhibiting today that I suspect is a bug.  If it's not a bug, then there must be a setting somewhere of which I'm not aware.

I have a couple of projects that I've developed initially in VS2003 (targeting the .NET 1.1 framework), maintained in VS2005 (targeting the .NET 2.0 framework), and recently upgraded to VS2008 (targeting the .NET 3.x framework).  These projects, rather than embedding image resources natively (that is, embedding the .png, .gif, and .jpg files as independent resources) I have some .resources files that contain string and image data.  Up to this point they've worked great.

However, I discovered today that once upgraded to VS2008 the resources were not loading.  My code for loading the resources is pretty simple:

ResourceManager mgr = new ResourceManager("MyApp.Res", Assembly.GetExecutingAssembly());
ResourceSet res = mgr.GetResourceSet(CultureInfo.InvariantCulture, true, false);

Note that my embedded resource file is named 'Res.resources', so the namespace for the ResourceManager is my application namespace followed by 'Res' because it's in the root of the application.

Now, with VS2008, the mgr.GetResourceSet() call was returning a NULL value.  Somehow my resources were not resolving! After digging a bit, I found that the '.resources' extension was being truncated off of my resource file during the embedding process so though it was present in the .exe, it's name didn't have the '.resources' extension appended!

My solution was to rename the file 'Res.resources.resources' and it worked.  Interestingly, the compiler doesn't exhibit this same behavior for the .resources files that it creates.  Has anyone else run into this or is there a setting for it?  Fortunately, I only lost about 15 minutes from discovering the issue to having it fixed, but it really feels like a hack more than a fix.

It is once again time for our very own Utah .NET User Group monthly meeting! In fact, in lieu of this Thursday being Valentine's Day, we've bumped the meeting date up to Tuesday (TODAY - 02/12/2008), same time, same place. We realize this is short notice (shame on us). We posted the meeting on the calendar several days ago, but failed to send out the email reminder until now for which we apologize.

This month, grab your canoes, oars, and life preservers and get ready to talk about STREAMS. Streams, though fundamental and routinely used, come in many different flavors. We'll be exploring streams from the ground up; from the ever-so-commonly utilized MemoryStream and FileStream types to the not-so-frequently used CryptoStream. Hey, we may even venture into the realm of the NetworkStream, the NamedPipeServerStream and NamedPipeClientStream. Time permitting, we will delve into the very cool compression streams (such as DEFLATE and GZIP).

Time: 6:00 PM
Date: Tuesday, February 12, 2008
Place: Digital Draw Network (10897 South River Front Parkway, South Jordan) Suite 300

This month's meeting is generously sponsored by TEKsystems.

Come out and enjoy the food, the friendship, and the fun!

If you ever incorporate XmlSerialization into your applications, you're probably aware of the SGEN.exe utility.  If not, you should become familiar with it.  Without going into details about it, suffice it to say that by using sgen.exe you can greatly improve the performance of your applications that rely on serialization (e.g., Web Service clients, et al).  Without it, your applications suffer in part because the .NET Framework generates a dynamic assemblies at runtime for the Xml-Serializable types in your application when first serialized.  Note that this hit is taken 'up front' and doesn't affect the runtime performance as much as the initialization performance of your application.

Well, since VS 2005 MS has included an option within the GUI on the Build tab called “Generate serialization assembly” with three options: Auto, On, and Off.  Unfortunately, though the intentions were there, this option is largely unusable for several reasons.  The same problems have carried over to VS 2008 with no changes.  On the bright side, however, there are other options at our disposal.

1. Use the sgen.exe from the command line.  Fun an exciting indeed!
2. Set up a Post-build event command line referencing sgen.exe.  Even more exciting!
3. The best option is to use the <SGen> MSBuild task which automates the process for us.  Awesome!

In fact, the main reason to use the <SGen> MSBuild task is to turn off the /proxytypes switch that the GUI throws in for us when the “Generate serialization assembly” is set to “On” which only has any meaning for Web Services.  Edit your .csproj file, dropping the following XML:

<Target Name="GenSerializationAssembly"
        DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource"
        Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)"
        Outputs="$(OutputPath)$(_SGenDllName)">
  <SGen BuildAssemblyName="$(TargetFileName)"
        BuildAssemblyPath="$(OutputPath)"
        References="@(ReferencePath)"
        ShouldGenerateSerializer="true"
        UseProxyTypes="false"
        KeyContainer="$(KeyContainerName)"
        KeyFile="$(KeyOriginatorFile)"
        DelaySign="$(DelaySign)"
        ToolPath="$(SGenToolPath)">
    <Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
  </SGen>
</Target>
<Target Name="AfterBuild" DependsOnTargets="GenSerializationAssembly" />

Now, when you build your project you'll get another DLL  with the name “assemblyname.XmlSerializers.dll”.  Simply deploy this DLL with your application to take advantage of the pre-generated serialization library.

Note:  Thanks to Kiwidude for the pointer on the MSBuild task.

As many who read my blog may already know (if nothing else because of proximity to me and this state of Utah), that President Gordon B. Hinckley passed away this evening (01/27/2008).  While I usually refrain from anything religious or centered around things non-technical (except for a few notable departures), I thought I would post this information as it's important to me.

Gordon B. Hinckley has been a fixture in my life for years.  For almost half of my years he has held the distinction of being the President of the Church of Jesus Christ of Latter-day Saints, and the prophet to whom I most related.  As child I recall President Spencer W. Kimball with distinction, and Presidents Benson and Hunter through my adolescent years were instrumental in my upbringing.

President Hinckley was an amazing individual, having served the Lord and His Church his entire life.  I distinctly recall a time when we were at my grandparents house in Las Cruces, NM watching conference.  Pa, my grandfather, expressed his great respect and admiration for President Hinckley (then a counselor to President Benson).  It was then that I began really listening to him and trying to follow his counsel.  I grew to love the man and have great admiration for him.

He shared a unique and brilliant wit in his talks and his wisdom was unsurpassed.  He will be missed.  At the same time, I'm happy for him, as he led a wonderful life and has undoubtedly been reunited with his lovely bride beyond the veil.

We are very excited and happy to welcome Aaron Joseph Zupancic into this wild world!  The youngest of five children, Aaron has four older sisters.  In other words, 5 moms.  I fear for his well-being!

Seriously, though, Aaron was born on January 8th, 2008 at 8:19 AM, weighing in at 8 lbs 10oz.  What a wonderful blessing he is to our home!  Mom and baby are doing great and we expect them home this weekend.

On a selfish note: we can finally get some cool toys around here! (no offense to his sisters .

Tonight we, at the Utah .NET User Group, will be putting on a special event: Visual Studio 2008 InstallFest.

We're very excited to be able to put on such an event; a big thanks goes out to Craig Berntson for working with the folks at Microsoft to acquire the DVDs.  In fact, we were able to acquire 35 such copies to give out to attendees.  So, bring your laptop and a power strip and come join in the festivities, it'll be a great time!

Place: Digital Draw Network - Suite 300 (10897 South River Front Parkway, South Jordan)
Time:  6:00 PM
Date:  Thursday, January 10th, 2008 (tonight)

Alright, there has been a particular issue with the Regular Expression Builder that I've known about since its creation and it's long bugged me.  I haven't, until today, taken the time to address the issue.  Essentially, in order to maintain the root namespace within the regex assembly created, I had created a custom Attribute (AssemblyBaseNamespaceAttribute) that was baked into the target DLL.  This hasn't truly proven to be an issue (at least when running on Windows), though the compiler would warn you when referencing it because the RegexAssemblyBuilder.exe application wasn't to be found.  It was more of an annoyance.  However, as I learned today, it does seem to be an issue when running on Linux/Mono.

Now I had the incentive I needed to fix the problem.

So, today I present a minor (but important) update to the Regular Expression Builder.  Version 2.0.0.1 provides two updates:

• The ability to save a 'Release' version of the assembly.  This version is saved to a \Release folder beneath the project path and is created without the AssemblyBaseNamespaceAttribute so the dependency is no longer there.  Applications should reference this DLL and this is the one you should deploy.  However, when making changes, use the original as it still has the attribute.
• You can now TAB through the pattern field in the regex editor form.  If you want, however, you can still insert TABs (ASCII 9) within your regular expression in the Zoom window via CTRL+TAB.  This is particularly helpful if you want your regular expression to be broken up onto multiple lines for readability and/or to comment it and use the IgnorePatternWhitespace option.

Download it here

Due to popular demand I (finally) got around to updating my Regular Expression Assembly Builder Tool.  If you're not familiar with it, you can read more about it and its history here and here, but suffice it to say, it's a handy little utility that compiles regular expressions into their own assembly (dll).  There is a lot of power behind this, not the least of which is that you can effectively pre-compile your regular expressions for your application and gain some performance improvements.  You can read more about it in my aforementioned posts.

The updates to the utility include the following:

• NEW: Upgraded to version 2.0.0.0.
• NEW: Upgraded to VS.NET 2008, .NET 3.5.
• UPD: Added resizability to regex dialog, supporting a larger text field for regex entry, line breaks, tabs (with a tabstop of 3), etc.
• NEW: Added scrollability to editor panels rather than not at all.
• NEW: Added support for a command-line-specified DLL to load.
• NEW: Added support for hierarchical (namespace) representation of regular expressions.
• UPD: Context menus add regular expressions to the hierarchy based on the user's selection.
• FIX: Fixed issue involving the various RegexOptions checkboxes where an invalid configuration of options could be selected (particularly involving ECMAScript, Multiline, and Singleline.

So, apart from some nicer UI interactions than in previous versions, this version most notably includes

1. Organization of your regular expressions my namespace.
2. Alphabetical listing of regular expressions.
3. The ability to provide an argument on the command-line designating the DLL to load.

Let me know what you like and/or don't like about it and I'll see what I can do to improve it for you!

Download it here

Enjoy!

I was working with a customer today that, after upgrading to the latest version of our software, was running into an error that I had never seen before.  The product, as you may be aware, is a web-based Product Configurator for Microsoft CRM.  Historically, our upgrades have been very clean and easy, but today the customer received the following error message when attempting to launch the application:

The file or directory is corrupted and unreadable.

The error was occurring at launch (during the initialization of ASP.NET) and was caused by an IOException.  Inspecting the call stack it was apparent that it was happening during the System.Web.HttpRuntime.FirstRequestInit() method while loading the assemblies from the \bin folder (System.Web.HttpRuntime.PreloadAssembliesFromBin() method).

My first thought was that something security-wise was amiss.  So, via Windows Explorer, we inspected the security properties on the folder for the website.  Sure enough, some credentials were messed up so we fixed those; but the application continued to fail with the same error.

Something in the back of my mind told me it was still security related.  After considering it a bit the answer was obvious.  We proceeded to open \Windows\Microsoft.NET\Framework\vX.X.X\Temporary ASP.NET Files to the folder for the application.  Upon drilling down the folder tree Windows reported the exact same error.

To fix it, all we had to do was fix the security settings on the folder, perform a CHKDSK, and delete the application's folder in the \Temporary ASP.NET Files folder.  After that, everything ran beautifully.