However, we have used the Microsoft FlexGrid quite extensively in our VB6 (now VB.NET) components and it does not support 64bit, therefore we decided to build a compatible control which wraps the existing WinForms DataGridView control.

We discovered quite early on that the properties set through the designer of an ActiveX control does not generate designer code, but instead it is serialized as a resource and restored through the OcxState property.

Always being the one to reduce the workload I devised a way of extracting this information so that we can redo the designer set properties. I found out that I could give the control another OcxState from another ResX and I could just look at the changed properties.

In the project (download below) I created a form with the desired control on it, I hacked around with the designer generated code to allow me to override the OcxState.

private readonly AxHost.State state;

public DummyForm()
    : this(null)
{
}

public DummyForm(AxHost.State state)
{
    this.state = state;
    InitializeComponent();
}

//
// axMSFlexGrid1
//
this.axMSFlexGrid1.Location = new System.Drawing.Point(69, 75);
this.axMSFlexGrid1.Name = "axMSFlexGrid1";
if (state == null)
    this.axMSFlexGrid1.OcxState = ((System.Windows.Forms.AxHost.State)(resources.GetObject("axMSFlexGrid1.OcxState")));
else
    this.axMSFlexGrid1.OcxState = state;

I used the ResXResourceReader and the ResourceSet classes to get the OcxState from my desired ResX source (the project that has the state in it I want to know). Then using reflection I compared the default state of the control (using the OcxState that the designer created) to the state I desired (with my own OcxState extracted from another ResX) and I now know what properties were changed on the designer.

In this project I have referenced the Microsoft FlexGrid but in theory it could be any ActiveX control.

Download Project

After creating a test application in various different configurations and testing it on several platforms we found that the ANSI version of AssocQueryString just did not work.

It was not until this evidence came to light that we finally found a connect article (in the depths of my browser history) describing this issue.

Our codebase might be quite rare (it is still currently 100% ANSI) and I would expect many to already be using Unicode… the workaround was to use it in Unicode and use conversions to interact with the rest of the codebase.

So yeah… hopefully others might find this elightening and save hours of hair pulling.

public static class ActiveX
{
    public static object Invoke(string @namespace, string @class, string method, params object[] parameters)
    {
        var progId = string.Format("{0}.{1}", @namespace, @class);
        return Invoke(progId, method, parameters);
    }

    public static object Invoke(string progId, string method, params object[] parameters)
    {
        var type = Type.GetTypeFromProgID(progId);
        var comObject = Activator.CreateInstance(type);

        return type.InvokeMember(method, BindingFlags.InvokeMethod, null, comObject, parameters);
    }
}

Download PresentationModel item template

How to use

It is a bit unusual the way I have written this. Instead of specifying the file name for the item, it is the view name that is to be used.

When prompted for the ViewName, specifying “MainWindow” will create:

A xaml user control called MainWindowView.xaml.

An interface called IMainWindowView.

An interface called IMainWindowViewModel.

A class called MainWindowViewModel.

(Some of this is very similar to the ViewModel code snippet)

iprop

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
	<CodeSnippet Format="1.0.0">
		<Header>
			<Title>iprop</Title>
			<Shortcut>iprop</Shortcut>
			<Description>Code snippet for an automatically implemented property on an interface</Description>
			<Author>Alex Boyne-Aitken</Author>
			<SnippetTypes>
				<SnippetType>Expansion</SnippetType>
			</SnippetTypes>
		</Header>
		<Snippet>
			<Declarations>
				<Literal>
					<ID>type</ID>
					<ToolTip>Property type</ToolTip>
					<Default>int</Default>
				</Literal>
				<Literal>
					<ID>property</ID>
					<ToolTip>Property name</ToolTip>
					<Default>MyProperty</Default>
				</Literal>
			</Declarations>
			<Code Language="csharp"><![CDATA[$type$ $property$ { get; set; }$end$]]>
			</Code>
		</Snippet>
	</CodeSnippet>
</CodeSnippets>

ipropg

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
	<CodeSnippet Format="1.0.0">
		<Header>
			<Title>ipropg</Title>
			<Shortcut>ipropg</Shortcut>
			<Description>Code snippet for an automatically implemented property with a 'get' accessor for interfaces</Description>
			<Author>Alex Boyne-Aitken</Author>
			<SnippetTypes>
				<SnippetType>Expansion</SnippetType>
			</SnippetTypes>
		</Header>
		<Snippet>
			<Declarations>
				<Literal>
					<ID>type</ID>
					<ToolTip>Property type</ToolTip>
					<Default>int</Default>
				</Literal>
				<Literal>
					<ID>property</ID>
					<ToolTip>Property name</ToolTip>
					<Default>MyProperty</Default>
				</Literal>
			</Declarations>
			<Code Language="csharp"><![CDATA[$type$ $property$ { get; }$end$]]>
			</Code>
		</Snippet>
	</CodeSnippet>
</CodeSnippets>

My only comment would be pick a language that is based on C-like syntax (rather than use Python or VB) because although the syntax may seem harder, the syntax is more transferrable to other languages and it would give you a head start.

In my personal experience, a book only served as a reference. I found books that taught me how to do something soon became too basic for my needs and often there are plenty of guides on the internet that is a good replacement. Instead you will find much of my library consists of reference books, hint, tips and advanced topics.

In each case I would get home, load it up and not find any problems at all. Well today was a different matter, I was able to pin point the exact issue. For some reason the library connects to the server but then stalls when receiving information from the server.

I should tell you know, this is not a perfect fix but it does the job. I did look into other options like switch socket blocking on and off and such other approaches, but it seems that if fgets reads more than 1 byte, it stalls. This is a bug in PHP that has hung around for a while.

I have changed the _readcall function to read the first byte, check it for failure then continue with the rest.

function _readcall()
{
	if (!is_resource($this->sCon))
		return false;

	// HACK : Workaround to fail fast
	$first = fgets($this->sCon, 1);

	if($first === false)
		return false;

	$sRead = '';
	do
	{
		$cRead = $first.fgets($this->sCon);
		$first = '';

		$sRead .= $cRead;
	} while ($cRead != CYTS_SYN && $cRead != CYTS_OK && strtoupper(substr($cRead, 0, 5)) != "ERROR");
	return $sRead;
}

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
	<CodeSnippet Format="1.0.0">
		<Header>
			<Title>View model property snippet</Title>
			<Shortcut>vmprop</Shortcut>
			<Description></Description>
			<Author>Alex Boyne-Aitken</Author>
			<SnippetTypes>
				<SnippetType>Expansion</SnippetType>
			</SnippetTypes>
		</Header>
		<Snippet>
			<Declarations>
        <Literal>
          <ID>name</ID>
          <ToolTip>Property name</ToolTip>
          <Default>Field</Default>
        </Literal>
        <Literal>
          <ID>field</ID>
          <ToolTip>Field name</ToolTip>
          <Default>field</Default>
        </Literal>
        <Literal>
          <ID>type</ID>
          <ToolTip>Type</ToolTip>
          <Default>object</Default>
        </Literal>
			</Declarations>
			<Code Language="csharp">
        <![CDATA[
    $type$ $field$;
    public $type$ $name$
    {
        get { return $field$; }
        set
        {
            if ($field$ == value)
                return;

            $field$ = value;
            SendPropertyChanged("$name$");
        }
    }
			$end$]]>
			</Code>
		</Snippet>
	</CodeSnippet>
</CodeSnippets>

I found a msdn forum post with exactly the same issue: http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/42647eff-ecb8-412c-a884-a152b6fdd40d

It turns out that it is NOT msbuild but it is SN.exe leaving the temp files behind when resigning assemblies. I suppose you could easily come to this conclusion when watching the build and those files are flashing by so quickly.

On reflection a custom task will not help either…

This post has more details on the issue with a link to a hot fix for Server 2003: http://blogs.msdn.com/pfedev/archive/2008/10/24/sn-exe-and-empty-temp-files-in-temp.aspx

If you are using Server 2008 I would not recommend installing it.

Original:

Recently at work we have be observing a very odd behaviour, a particular set of builds has been slowing by about 30 minutes every night.

We discovered that hundreds of temporary files were being created by the msbuild exec task. What happens is that the exec task will created a temp file, then use the temp file name to create a batch file with the command in it. In most cases it will delete the temp file and the batch file. If you are quick enough you can pause the build and look in the temp folder and observe these files.

Now the strange thing is we have observed a specific case of when msbuild will not delete that temporary file, thus adding a cumalative amount of time every night when it is trying to find a new temp file name. This occurs when we resign our assemblies using SN. If you use SN to verify the assemblies the temp file is cleaned up afterwards.

This is quite a baffling problem, when calling the same executable with a different command it just works, seems odd to me that it would cause such an issue. There is also little on the internet that hints at this issue, I suppose if people are careul and look after the servers with regular cleanup tasks this issue might never arise.

So at the moment to work around the issue we have written temp folder clean up tasks and a sceduled disk clean up task on the server. I might write a set of specific tasks wrapping the SN executable and its command line arguments to reduce the need for such measures.

If I can get any sort of grasp on the actual issue then I will create and link to an MSConnect issue.