When I came to Orlando, Florida for the Microsoft Convergence 2008 Conference I didn't expect to get such a treat.  I found out yesterday, shortly after my arrival that we were going on an outing to watch the Space Shuttle launch.  Boy was I excited!  I had no idea it was going to launch in the first place, but was even more excited to be able to witness the launch in person, and at night.

I vividly recall when the Space Shuttle Columbia landed just 30 minutes from my house (a night landing) at White Sands in NM but I wasn't able to attend that event.  In fact, I have wanted to see a shuttle launch since the Columbia first went into space; it set many of my dreams into motion, few of which will ever come true - though seeing a launch in-person has just now!

The event was amazing.  We were situated across the water from the launch pad (geographically, I'm not sure how far it actually was).  Right at 2:28 AM we saw the first billows of smoke rise from the launch pad, then the bright flare of the flames from the rockets.  The rocket, the size of a lit match's flame at arm's length, ascended rapidly but very silently into the night sky.  Perhaps most astounding and brilliant was the entire sky...not just the horizon where the launch took place, but the ENTIRE SKY turned a bright orange during the launch.  It appeared as though a small sun had risen.  The rocket was then engulfed in the low cloud coverage.

The rocket disappeared.  After a small delay of about 10 seconds or so we began to hear and actually feel the trembling and roar of the rocket boosters.  This got increasingly louder and more rumbling before waning.

Poetry in motion.

I've been putting together a small WCF service that allows a client to upload a file to a server for processing.  While the details of that are for another discussion, I want to focus on what should have been a simple operation but turned out to take up most of my afternoon and some of my evening: the generation of a client proxy class and configuration file.

By way of background, this particular WCF service is hosted by a simple Windows Service, runs (by default) under the Network Service account, and exposes a TCP end point for communication.  I have a setup project that takes care of the installation and registration of the Windows Service and auto-runs it when installation is complete.  This has been running great.

However, anytime I attempted to generate a proxy class for my service via the following command line, I would get some nasy error indicating that it “Cannot obtain Metadata from net.tcp://localhost:9999/myservice”.

svcutil net.tcp://localhost:9999/myservice/mex

My configuration file was as follows:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <system.serviceModel>
      <behaviors>
         <serviceBehaviors>
            <behavior name="mex">
               <serviceMetadata />
            </behavior>
         </serviceBehaviors>
      </behaviors>
      <services>
         <service name="MyService.ExampleSvc" behaviorConfiguration="mex">
            <host>
               <baseAddresses>
                  <add baseAddress="net.tcp://localhost:9999/myservice" />
               </baseAddresses>
            </host>
           
            <!-- default endpoint -->
            <endpoint
               binding="netTcpBinding"
               contract="MyService.IExampleSvc" />
           
            <!-- metadata exchange (MEX) endpoint -->
            <endpoint
               address="mex"
               binding="mexTcpBinding"
               name="MEX"
               contract="IMetadataExchange" />
         </service>
      </services>
   </system.serviceModel>
</configuration>

However, as I mentioned, everytime I attempted to retrieve the metadata via the /mex endpoint it failed.  Right off the bat I suspected that the error had to do with the types used in the [ServiceContract] class, but I brushed that idea aside thinking that for sure it was something in the configuration file.  So I kept on battling with it.

To that end, I created a very simple WCF service (in the same application) this time with an HTTP endpoint.  I had to change the Windows Service credentials to a user with elevated permissions to register the HTTP channel (Network Service won't cut it) because I didn't want to manually mess with my HTTP security settings.  Anyway, this was just a test.  To my chagrin, it worked first try; I was able to retrieve the metadata.

So I returned to the TCP service.

Fortunately (and I'm no WCF whiz...yet :), I found a helpful behavior that I could add to the .config file that saved the day for me.  By simply adding the <serviceDebug /> element with the includeExceptionDetailInFaults attribute to the mex behavior element I was able to get some diagnostics.

<serviceBehaviors>
    <behavior name="mex">
       <serviceDebug includeExceptionDetailInFaults="true" />
       <serviceMetadata />
    </behavior>
</serviceBehaviors>

Now, in the big, fat, honkin' exception stack that was output I saw immediately that one of the embedded types used in my [ServiceContract] implementation had a nested type that was not serializable.  Once I added [Serializable()] to the offending types (there were a few of them) and recompiled it worked like a champ!  So it turns out that my initial suspiscion was correct...I need to listen to my intuition more often!

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