Cook Computing

Until half an hour ago I didn't know that junction points are a particular type of reparse point. A reparse point contains data and a tag which identifies which file system filter is used to process the data. This provides an extension mechanism for NTFS.

Microsoft have provided several type of reparse point from Windows 2000 onwards:

• Symbolic links
• Junction Points
• Volume Mount Points
• Remote Storage Server

This page briefly explains what each of these are.

I installed Longhorn in a VPC image yesterday. Everything went very smoothly and the much reported delay during hardware detection was only 25 minutes. Whidbey and the Longhorn SDK followed. I now need to think of something interesting to implement.

I found the Longhorn Tweak Guide useful for explaining how to fix networking if you're using a static IP address.

Jon Lam mentions junction points, an NTFS feature I've found useful when developing .NET applications. Say the output from the various projects in your build are placed in \myproject\bin and the directory where these files are installed by your product's installer is \program files\myproduct.

myproject
+--bin

program files
+--myproduct

To build a dll and run it in the myproduct directory you either have to copy the file each time you rebuild or temporarily change the output directory of the project. The first approach is too irritating to contemplate and the second means that dependent assemblies may not build correctly if their reference to the dll assumes its location is the bin directory.

The solution is to create a junction point under the myproduct directory which links to the bin directory:

junction "\program files\myproduct\bin" \myproject\bin

myproject
+--bin

program files
+--myproduct
    +--bin*

The next step is to configure probing for the application so that the junction point bin directory is searched, by using a configuration file, for example:

<?xml version="1.0"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="bin" />
    </assemblyBinding>
  </runtime>
</configuration>

Finally delete the assemblies in the myproduct directory which you want to be picked up as you rebuild them, and when you run your application the assembly resolver's probing process will load them from the myproduct\bin directory which is really the \myproject\bin directory. Note when probing, only subdirectories of the application's appbase directory are eligible and so you can't just point privatePath to \myproject\bin.

Ingo Rammer has made available the slides and samples from his talks at DevWeek London. There's some interesting stuff here. One point that I noted in the Top 10 .NET Remoting Real World Issues presentation was his suggestion of using server side sponsors for keeping remoted objects alive in .NET remoting. He illustrates how the use of client side sponsors can fail when a firewall prevents calls from the server to the sponsor object on the client. The solution is to place the sponsor object on the server and get the client to periodically ping the sponsor, using a background thread, so that the sponsor knows that the client is still interested in the remoted objects. As Ingo says, this is pretty much what DCOM does.

One other scenario in which this could be useful is where you want to minimise the number of remoting calls per second as much as possible. Instead of server -> client sponsorship calls for individual objects, you get a single periodic client - server call. An alternative would be to increase the length of the leases but you might not want to do this in some situations.

I tried installing the Longhorn preview on a Shuttle SN41G2 last night. Everything worked fine except the Ethernet drivers failed to start. The idea of working on a machine without a network connection does not appeal to me so plan B is to run Longhorn in a VPC session until the next release, by which time issues like this will hopefully have been sorted out. No idea when that will be though.

Rebecca Dias mentioned the Essential WSA: Programming Web Services with WSE course at DevelopMentor. The course is also being held in London 27th-30th April. I booked a place yesterday.

Using a C# delegate the other day I thought it would be useful if it was unnecessary to define delegate types manually, for example if an assembly you're using also provided delegate types for all the methods you might call. This seemed like something that could be generated automatically via Reflection.Emit and a Google search quickly threw up an interesting blog entry by Joal Pobar which describes how to do this. Joal's code could be wrapped up in a tool which could be used in your build process to generate delegate types for specific interfaces or classes.

If you want to use a generated delegate asynchronously you need to also generate the BeginInvoke and EndInvoke methods, as in the following additional code:

Type[] paramTypes2 = new Type[parameters.Length+2];
for (int j = 0; j < parameters.Length; j++)
{
	paramTypes2[j] = parameters[j].ParameterType;
}
paramTypes2[parameters.Length] = typeof(AsyncCallback);
paramTypes2[parameters.Length+1] = typeof(object);
methodBuilder = typeBuilder.DefineMethod("BeginInvoke", 
  MethodAttributes.Public | MethodAttributes.HideBySig 
    | MethodAttributes.NewSlot | MethodAttributes.Virtual, 
  typeof(IAsyncResult), paramTypes2);
methodBuilder.SetImplementationFlags(MethodImplAttributes.Runtime 
  | MethodImplAttributes.Managed);

Type[] paramTypes3 = new Type[1];
paramTypes3[0] = typeof(IAsyncResult);
methodBuilder = typeBuilder.DefineMethod("EndInvoke", 
  MethodAttributes.Public | MethodAttributes.HideBySig 
    | MethodAttributes.NewSlot | MethodAttributes.Virtual, 
  targetMethod.ReturnType, paramTypes3);
methodBuilder.SetImplementationFlags(MethodImplAttributes.Runtime 
  | MethodImplAttributes.Managed);

Seen on one of the Mono lists: version 0.1 of Nemerle - "a statically typed functional language with well founded .NET" - has been released by a team at Wroclaw university.

Key features of the language are claimed to be:

• simplicity
• C#-like syntax
• .NET integration
• an easy to use object system (derived directly from the .NET)
• easy access to both functional and imperative features
• powerful code-generating macros
• variants [subtypes]
• pattern matching
• static and on-demand dynamic typing
• type inference