Category Archives: .NET Development

How to calculate the current Stardate in C#

Recently, one of our developers needed to calculate the Stardate using C#.NET.  After much internal mental gymnastics regarding TOS, TNG, and newer calculations, the following code was produced:

string stardate = DateTime.Now.Year.ToString() + “.” + ((int)(DateTime.Now.DayOfYear / 3.65F)).ToString();

The developer was immediately harangued about inconsistent time zone support.  Of course, we are not exactly sure how time zones work in outer space….

…and management wants to know which customer CR this line of code now belongs to.

Uninstalling the .NET Framework… the hard way

One of our clients recently lost a server due to a hard drive controller failure.  While RAID was enabled, the controller failure resulted in some odd corruption on the server.  After restoring all the necessary backups, we noticed that the .NET based applications would not launch.  Odd… .NET is installed, I can see the v2.0.50727 directory, it all seems to be installed.

Pulling out the old book of first line of support tasks, we

1st: we attempted to reinstall dotnetfx.exe (.NET 2.0)
This failed with the following error

Setup cannot continue because this version of the .NET Framework is incompatible with a previously installed one. For more information, see

2nd: we attempted to uninstall the .NET framework via the Add/Remove programs function
This failed with a “cannot launch uninstall package”. 

3rd: we attempted to manually uninstall and reinstall the .NET framework via the Microsoft recommended methods documented at  During the reinstall of dotnetfx.exe, we once again received the “Setup cannot continue because this version of the .NET Framework is incompatible…” error
(Side note:  Finding and downloading the MSICUU2.EXE tool proved to be remarkably difficult.  For future reference, I have included the installer file at this link)


Then we remember an article we read a couple of years ago about a .NET clean-up tool which works wonders on corrupted .NET installs.  The tools is available at

We ran the tool, reinstalled .NET and all was well on the server…. at least until next time

Visual Studio designer failures “type could not be read” errors

In one of our larger development projects, we began to notice the following designer error when opening forms with user controls embedded :

Type  could not be read from the data in line N position N.  The type’s internal structure may have changed.  Either implement ISerializable on the type or provide a type converter that can provide a more reliable conversion format, such as text or an array of bytes.  The conversion exception was: Unable to load type [CLR Type Information]

Our first point of confusion was the line N position N information.  The CLR Type referenced by the error did not exist in any code file at Line N.  How could the designer be failing to open a form by executing code which didn’t exist at the location the designer said it was failing at.

Our second point of confusion was that removing ALL references to the offending type still resulted in the designer error occurring when opening the form.

OK, time to brew a pot of coffee and put on our thinking caps….

<Coffee gone, solution found>

The cause
We tracked the cause (not the root problem… we’ll discuss that in a minute) to the user controls.  In several of the user controls, there exists get/set accessors which take an IList<T> collection using the following code pattern


public partial class ListManagerDisplayControl: UserControl

public ListManagerDisplayControl()

private Guid _CustomerGUID;
public Guid CustomerGUID
set { _CustomerGUID = value; }

public IList<Type> DataList
set { _DataList = value;}
get{ return _DataList; }


The problem is the Get/Set accessor.  When you drop the usercontrol on a form, the designer attempts to populate all of the properties in the form.designer.cs which is pretty standard stuff… until you look at the DataList property…. in the designer, the IDE will produce lines of code similar to


// uiListManagerControl
this.uiListManagerControl.Location = new System.Drawing.Point(x,y);
this.uiListManagerControl.Size = new System.Drawing.Size(x,y);
this.uiListManagerControl.DataList = new List<Type>();



The problems turns out to be the uiListMangerControl.DataList = new List<Type>();

The Real Root Cause
OK, for those keeping score, the line uiListMangerControl.DataList = new List<Type>();  should not have any impacts on the designer and certainly would not result in the error we were seeing.  And you would be right.

Enter the resource file….

To support localization, control properties can be stored in the form.resx file.  In our case, the property was being populated by the following form.designer.cs line of code:

// uiListManagerControl
this.uiListManagerControl.Location = new System.Drawing.Point(x,y);
this.uiListManagerControl.Size = new System.Drawing.Size(x,y);
this.uiListManagerControl.DataList = ((System.Collections.Generic.IList<Type>)(resources.GetObject(“uiListManagerControl.DataList “)));


Hey, that looks like it serialized the IList<> object… interesting.  A quick peek at the resource file showed the following

<data name=”uiListManagerControl.DataList”


And behold, the line number of the binary data exactly matched the line number being reported in our error.


Solution One
Remove the Get portion of the accessor.  If no data is returned by the user control DataList property, the IDE designer will not put anything into the designer file.  (Be sure to delete the offending entries from the designer file or the error will continue)

This solution worked well for us as the IList<> collection type is a reference type.  There is no need (in our scenario) to return another pointer to the same location in memory… the owning form already knows where the data is.  The user control (in this case) is merely a reusable display for common data

Solution Two
Use the [DesignerSerializationVisibility()] attribute to define how the property is serialized.


Additional Notes
In our case, the error was created by an IList<> type.  Based on our research, this error can (and probably will) occur for most complex types when exposed as properties on a user control.


OK, problem solved… time to shoot some Nazi Zombies…