My Doc's Got No Nodes

Looking for a punchline since 2002

If you’re seeing an error in the event log that looks like this:

Activation context generation failed for "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\ia64\msvsmon.exe". Dependent Assembly Microsoft.Windows.Common-Controls,language="*",processorArchitecture="ia64",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0" could not be found. Please use sxstrace.exe for detailed diagnosis

And it’s occurring at about 00:30 every day, it seems to be caused by the scheduled task ProgramDataUpdater. It looks like it’s choking on the ia64 binary, and if you don’t need the Itanium version you could resolve it by renaming or deleting the exe, similar to this KB article:

http://support.microsoft.com/kb/2021839

In previous versions of .net (x64 .net 2), as a result of experimenting with the profiler and forming beliefs (whether true or false :-) that:

  1. property accesses are expensive
  2. bounds checks are not eliminated for static member arrays (this one was correct, as Greg Young proves).
  3. parallel array accesses do not have the bounds checks optimized away

So, for consistency, I always wrote loops like this, with a local reference to the array and a variable in the loop scope holding the end limit.

int z = 0;

var localArray1 = memberArray1;
var localArray2 = memberArray2;

for (int x = 0, length = localArray1.Length; x < length; x++)
{
    z += localArray1[x] + localArray2[x];
}

Recently, I re-examined this practice with Visual Studio 2010 RC and the disassembly window. I wanted to find out what the best pattern would be consistency and allowing the JIT to hoist the bounds checks, eliminating them from the per-iteration part of the loop.

.net 2

x86 and x64 JITs were both unable to remove the bounds checks.

Rewriting the for loop to read

for (int x = 0; x < localArray1.Length; x++)

Allowed the x86 JIT to eliminate one of the bounds checks. The x64 JIT still had both.

.net 4

The x86 JIT still had both bounds checks. The x64 JIT eliminated one.

Rewriting the for loop to read

for (int x = 0; x < localArray1.Length; x++)

The x86 now had only one bounds check. The x64 eliminated both.

Conclusions

  • Don’t use a local variable to hold your array stopping condition.
  • Experiment with both ‘Any CPU’ and ‘x86’ if possible.
  • Check out the disassembly (step-by-step explanation by Vance Morrison).

Suppose you’ve got a NAS, or *nix box which has an rsync daemon running on it.

You’ve also got the convenient cwrsync bundle installed on your Windows box.

Now you want to be able to copy all the files in a folder on the windows box, say:

> C:\foo\my spaced path\things

to and from the rsync module on your server.

To copy from the server to Windows

"c:\Program Files (x86)\cwRsync\bin\rsync.exe" -v -r -c rsync://@server/module /cygdrive/c/foo/"my spaced path"/things

This assumes the default installation path for cwrsync, you should drop the “ (x86)” if you’re not running on a 64-bit version of Windows.

The parameters include

  • -v for verbose
  • -c to always test file checksums rather than timestamps. If you’re happy that the timestamps are reliable, replace it with a –t to use (and copy) the timestamps.
  • -r for recursive.

The path on the Windows box has been munged to cygwin’s standards to look like a *nix path.

  • The slashes all go forwards
  • The /cygdrive/c is the equivalent of C:
  • Any directory names that have spaces need a quote around their name, not around the path as a whole.

The path to the server specifies the rsync protocol, and the server name and module (like a share name in Windows/Samba/CIFS). I’ve not shown any user or password specification.

To copy from Windows to the server

"c:\Program Files (x86)\cwRsync\bin\rsync.exe" -v -c -r --no-perms --chmod=ugo=rwX /cygdrive/c/foo/"my spaced path"/things/ rsync://@server/module

Note the trailing slash after the Windows folder name. Without that, you’ll get a subfolder called “things” created under the module on your server.

I added the no-perms and chmod parameters because otherwise the ACLs that rsync placed on the copied files gave no rights to anyone.

Just try giving a friend a C90 and asking them to copy a couple of albums for you.

(I’m including Part 1 in the title because there’s a possibility I’ll be adding to this topic.)

If you look for information about using Plain Old CLR Objects with RIA services (or using RIA services without Linq to Entities) you’ll see a few articles telling you how easy it is to use your own business objects from a DomainService - If you simply stick the [Key] attribute above a property that uniquely identifies your object, all will be well.

Except it’s not necessarily true. It all depends on how ‘smart’ your objects are, and how you expect it to work. If you have the (accurate) mental model of the objects being serialized and deserialized between client and server then you’re probably going to be OK.

On the other hand, if you’re working with less dumb objects that do more than just hold database fields, and you think of the RIA services as more like remoting then, like me, you’re going to be disappointed.

To be honest, my first clue should have been that everything has to be get/set and the classes need parameterless constructors. My ‘business objects’ had some internal state that they used to map themselves back to the database, so I marked that with [Exclude] attributes.

I tried sending these objects to the client via a query method, and then accepting them back to the server as parameters on an [Invoke] method. All the internal state had gone. But that was because they weren’t the same objects I returned from the query, they were newly constructed objects with the same values in their public properties.

The lesson was that there’s no reference tracking going on between client and server. If you send the client an object, it will be cloned on the client side. If that object is modified and passed back, the server gets a new object with all the values – not the original object with new values applied.

This probably seems obvious to many people, particularly those who have used similar frameworks (like the view model stuff in ASP.NET MVC) but it’s not something I saw explicitly called out in any of the explanations of using Silverlight RIA services with POCO.

Previous 6 of 8 Next