# SerializationException: the constructor was not found

I just finished another post at the Cozi Tech Blog, Se­ri­al­iza­tionEx­cep­tion: the con­struc­tor was not found

# Building a REST Web Service, day 1

My first project at Cozi is to build a simple REST-style Web Service. Nobody here has done that before.

The first thing that I'm trying to get going is a simple URL rewriter, using an ASP.NET HttpModule.

I'm running Vista as my de­vel­op­ment desktop for the first time. So far, not bad, but there are lots of new quirks to get used to. I've been a good boy so far and I've left the User Access Control stuff enabled, so that I'm not running with ad­min­is­tra­tive privileges by default.

It's my first exposure to IIS 7. I must say that the IIS UI is much improved (a low bar to continue.

# Serializing a NameValueCollection

I had a NameVal­ueCol­lec­tion embedded inside a larger object. I needed to serialize the larger object into XML and back. Un­for­tu­nate­ly, NameVal­ueCol­lec­tion is not XML se­ri­al­iz­able. Why I do not know.

A blog comment from Tim Erwin got me started in the right direction. Implement IXmlSe­ri­al­iz­able and do the work by hand in ReadXml and WriteXml.

Tim's im­ple­men­ta­tion turned out to be overly simple. It didn't handle an empty collection well, nor did it leave the XmlReader in a good state.

I used SGen to examine the de­se­ri­al­iza­tion of a List<String> to figure out what else needed to be done.

The following ReadXml seems to work. If I expected to receive XML from continue.

# Multilingual

This week, I have written code in C#, C++, Managed C++, C, WiX, NAnt, Ac­tion­Script, VBScript, JScript, cmd batch, NMake, HTML, XSLT, and Ruby. And I will probably get some Python in before the weekend is over. <boggle/>

# NUnit calling CppUnit

Over the last few days, I've been adapting an existing native C++ library so that it can be called from managed code. I had written a large number of unit tests with CppUnit and I wanted to be able to call the tests from NUnit.

I suppose that I could have written a new CppUnit TestRunner so that I could call it from NUnit. Instead, I took the cheap-n-dirty route, playing with #define and include paths. It took less time to get working than it did to write this blog post.

Here's the original native CppUnit test code

//-------------------------------
// native\FooTest.h
//-------------------------------

#include <cppunit/extensions/HelperMacros.h>

class FooTest : public CppUnit::TestFixture
{
CPPUNIT_TEST_SUITE( FooTest 
continue.

# NVelocity: loading templates from embedded resources

In last week's tip on using the NVelocity template formatting engine, I described what to set to load a template from an absolute path.

Here's the magic necessary to get NVelocity to load a template from an embedded resource:

VelocityEngine engine = new VelocityEngine();
ExtendedProperties properties = new ExtendedProperties();
properties.AddProperty("resource.loader", "assembly");
properties.AddProperty("assembly.resource.loader.class",
"NVelocity.Runtime.Resource.Loader.AssemblyResourceLoader, NVelocity");
properties.AddProperty("assembly.resource.loader.assembly", "StencilFormatter");
engine.Init(properties);


# NVelocity templates and absolute paths

We've started using the NVelocity template formatting engine. We were absolutely stymied for an hour, trying to figure out how to get it working with an absolute path to the template file, instead of the relative path shown in the doc­u­men­ta­tion.

The trick is to set file.resource.loader.path. Here's how to load C:\foo\bar\­some­file.vm:

ExtendedProperties props = new ExtendedProperties();
props.AddProperty("file.resource.loader.path", new ArrayList(new string[]{".", "C:\\"}));
velocity.Init(props);

template = velocity.GetTemplate("foo\\bar\\somefile.vm");


# Never Sleep(0) in an Infinite Loop

I ran into a problem installing some COM+ components today. The installer was using Regsvcs.exe to register each COM+ component. I noticed after a while that the installer wasn't making any progress and that my dual-proc system was stuck at 50% CPU uti­liza­tion. I attached a debugger to the offending process, regsvcs, and found that it was stuck in the following infinite loop (dis­as­sem­bly courtesy of Reflector):

internal void System.EnterpriseServices.CatalogSync.Wait()
{
if (this._set)
{
RegistryKey key1
= Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Classes\CLSID");
while (true)
{
int num1 = (int) key1.GetValue("CLBVersion", 0);

continue.