// do something here

We have had bad experiences in the past deploying desktop applications based on the .Net Framework version 3.5, largely due to the huge payload required on the end user’s system to run our relatively simple application.

When SP1 of Visual Studio 2008 was announced to have an option to trim down the bits to be downloaded, we were naturally excited to put it into place on our newest product. In a VB.NET application, this option is called “Client-only Framework subset”, it is on the Advanced Compiler Settings window shown by clicking Advance Compile Options… on the Compile tab of My Project, and in a C#.NET application, the Client-only Framework subset check box is right under Target Framework on the Application tab shown by right clicking on the project file and selecting Properties.

Excited until, of course, we tried for the very first time to run the ClickOnce installer for our product on a clean Windows XP SP3 virtual machine and received the following error:

Unable to install or run the application. The application requires that
assembly Sentinel.v3.5Client Version 3.5.0.0 be installed in the Global
Assembly Cache (GAC) first.

I did some quick investigating and found that, for the most part, the suggested solution was to turn off the client only subset option. Bugger!

This did not sit well with me, so I did a little more digging. I did not think that there were any kind of items added to the code that would require namespaces not included in the client only framework, so I went through all of the property pages for the project.

On the Publish tab, I clicked on Preqrequisites, and noticed that my application was including prerequisites for Windows Installer 3.1, .NET Framework 3.5, and SQL Server Compact 3.5. On a lark, I turned off the prerequisite for .NET Framework 3.5 and turned on the prerequisite for .NET Framework 3.5 SP1, built the ClickOnce installer, and voila! It is now working like a champ.

So I have, for the most part, got the new development machine all set up and running pretty well. But ah, there is always a fly in the ointment…

I have a Windows Mobile client application that talks to a WCF service to move data back and forth. I have been using a batch file that I created that ran the NetCFSvcUtil.exe program included in the Power Toys for .NET Compact Framework 3.5. This tool reads information from the provided URL of the web service and creates C# or VB.NET source files that can be included in your project.

And of course, this utility program does not work on my shiny new Windows 7 RC machine, it gives the following error:

Attempting to download metadata from 'http://www.site.net/Service.svc'
using WS-Metadata Exchange or DISCO.
Error: An error occurred in the tool.
Error: Error in the application.

Some searching for this problem yielded the following posts:

NetCFSvcUtil.exe and Windows 7

Ambiguous error message from NetCFSvcUtil.exe

These links appear to indicate that the NetCFSvcUtil does not work on Windows 7 and there is no workaround just yet. And now I have a nice shiny new VirtualBox Windows XP image that contains installs of the .NET Compact Framework 3.5 with the Power Toys, and a copy of my old batch files, along with a shared folder that I can grab the files when I need them. Thanks Microsoft!

However, it appears that Microsoft does not have the market cornered on “D’oh!” backwards compatibility moments. It appears that some users have had some issues with the load times of Firefox 3.5, and believe it or not, removing the cookies and temporary internet files associated with IE can actually help. I will give you a link to look at while you ponder this interesting nugget.

The Firefox 3.5 fiasco

I guess you could say that Mozilla is a big believer in the More Randomer theory.

People like nicely formatted numbers on their reports and web pages. For example, if I needed to display the results of a division where the dividend is 1 and the divisor is 3, typically I would display that as 0.3 (the number formatted to 1 decimal place) instead of 0.3333333.

So imagine my surprise when I had a single detail line in my report where a value is shown as 6.0, but in the total line right below it (which utilizes the same data since there is only the one detail line), the same value is displayed as 5.9.

We finally tracked the problem down to a conversion between a float to a double. It appears that the .NET runtime is not able to take a float value of 5.95 and convert it exactly to a double of 5.95, the conversion sets the double to 5.94999980926514. As a result, when this value was sent into the string formatting function, the value would round down instead of rounding up. Keep in mind that the divisions actually come out right, whether they are floats or doubles. As I stepped through the code, all looked well since the float variable was calculating as 5.95 (119 divided by 20), but this was of course before the conversion and formatting.

As I think about it, I was pretty lucky to find this little glitch, as it will only manifest itself when for certain dividends when the divisor is a multiple of 20. (The 1 decimal place round off error happens at multiples of 0.05, or 1 / 20.) Feeling interested, I decided to do a little experimentation. I am married and over the hill, what else am I going to do on a Friday night?

I set up a .NET C# console application to test out the divisions, conversions, and string formatting, and reporting on when the formatted string of the double varies from the formatted string of the float converted to a double. The divisor would loop from 20 to 1000 by 20, and the dividend would loop from 1 to 1000. The final results were:

Divisions tested: 50000
Divisions failed: 916
Failure percentage: 1.83 %

As expected, the divisor of 20 shows the most variations, and dropped off to only 4 variations with a divisor of 1000 (at 350, 450, 650, and 950).

The moral of the story is when it comes to floats, just say no. We went into the code and removed all the float variables and casts and changed them all to doubles.

So I am cruising through the ASP.NET C# MVP web project we are working on, and happened upon this method (again, the names were changed to protect the not so innocent):

private void mView_LoadObjects(object sender, EventArgs e)
{
    try
    {
        try
        {
            BusinessLayer.Class1 bizClass = new BusinessLayer.Class1();
            mView.objects = bizClass.GetObjects(mView.ID1, mView.ID2);
        }
        catch (Exception ex)
        {
            System.Diagnostics.Debug.WriteLine(ex.Message);
            throw;
        }
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine(ex.Message);
        throw;
    }
}

However, the fun didn’t stop there.  A little further down the class, I found this:

private void mView_LoadOtherObjects(object sender, EventArgs e)
{
    try
    {
 
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine(ex.Message);
        throw;
    }
}

I am thinking that the catch block on this second example was not hit very often.

Another nicety that I happened upon, this time from the C# realm. The names were changed to protect the innocent.

theClass.uniqueID = (id != null) ? id : null;

Looks like someone just figured out how to use the ternary operator and was determined to use it.