Cook Computing

Off on a two week x-c skiing vacation to Norway this weekend. I'm taking my laptop so will be doing some XML-RPC.NET work. As it happens I wrote most of the original beta1 XML-RPC.NET code during a week in the Engadine valley last February. A few hours of skiing each day clears the mind wonderfully for some serious coding.

Until I get back the samples at Eraserver may become unavailable - depending on whether I get to upgrade my trial account today.

Posted this to the dotnet discussion list:

Brad Wilson wrote:

> If you intend to make this adjustment, then I
> would say two things must happen. First, users
> must have a security dialog like is present for
> ActiveX controls; and second, it must also use
> digital signatures to enhance the user's level
> of trust (they know something is signed by ABC
> Corp. and has not been tampered with).

The presence of a certificate for ABC Corp does not solve the problem. I may not trust ABC Corp enough to want to run their code in the MyComputer zone. I may be perfectly happy to run their code in the Internet zone for example using a smart client to post weblog entries back to a Blogger-type website but I dont want to give them the chance to do anything potentially harmful to my machine whether by intention or by accident. ABC Corp may say their MSI script is just going to give themselves Internet zone permissions but how do I know that (well, I think I know just enough about .NET security to check that but the average end-user wont)?

Even if we trust the ABC Corps MSI script or check that it does indeed only give their code Internet zone permissions (or even configure it manually), there is a more fundamental problem. The overall message from Microsoft seems to be: were not sure whether code running in the Internet zone is completely secure so were disabling it by default and letting you choose whether you trust it enough to run code in this zone. But the only evidence we have as to whether this is safe is the fact that Microsoft does not appear to trust it enough to enable it by default. So the sensible approach is for us not to trust it either. Which is disappointing given the promise of smart clients, particularly because we probably end up with less security because of possible end-user confusion.

Interesting shift in .NET security policy detailed on this posting on the dotnet list. Obviously lacking confidence that the .NET "sandbox" is secure, Microsoft is shifting the responsibility for the risk to the end-user by not allowing smart clients or .NET web page controls to run in the Internet zone by default. Therefore if security is compromised it is the fault of the end-user, not Microsoft. Chris Anderson suggests that this policy may be reversed in future and Internet code re-enabled. Maybe they have discovered some flaws in .NET security which just need some time to be fixed? Of course, the end-user can re-enable Internet code with various degrees of granularity but will that be a sensible thing to do if Microsoft don't trust the sandbox enough to make it available by default as originally intended?

I've been side-tracked the last couple of evenings onto the challenge of launching .NET smart clients without having IE pop on your screen when the client ia launched. The result is a simple tool called nexec which is described in more details on the Tools page.

nexec loads assemblies in a pretty simplistic way at the moment but as I discover the cases where it doesn't work I'll attempt to extend it to handle them.

I discovered why MathApp would not run as a smart client unless you gave it LocalIntranet permissions: I was setting the Active property of the form. This is presumably not allowed for Internet zone apps because in the case of a control it would be grabbing focus and possibly compromising the code in the surrounding form.

This MathApp should run from the Internet zone without any special configuration (as long as you connect to the MathService XML-RPC service at EraServer).

This MathApp will run but all math requests will fail unless the app is given at least local Intranet zone permissions. There is no MathService running at CookComputing.com and Internet zone apps are not allowed to connect to servers other than the server they were downloaded from.

I also had to make a change to the CookComputing.XmlRpc.dll assembly by giving it a strong name and adding the following obscurely documented attribute (from the System.Security namespace):

[assembly: AllowPartiallyTrustedCallers]

MathService XML-RPC.NET service at EraServer has been updated - note new URL:

http://www.dev1.eraserver.net/cookcomputing/math.aspx

The MathApp client which calls this service has been updated at these URLs: MathApp and MathApp. Two URLs are provided so you can test the different security settings for when a client connects to either the site it was downloaded from or another site.

My account at EraServer has been updated to .NET RTM. I haven't updated the sample MathService dll from a beta 2 build yet. Until I do this, probably this evening, the service won't be available.

I'm still working on unit tests for XML-RPC.NET. I'm going to use NUnit when a .NET RTM version is released (hopefully fairly soon according to a posting from Philip Craig at the NUnit site). For the time being I'm writing test cases and calling them from hand-written code rather than automatically through the NUnit framework.

I'm new to this more structured approach to unit testing but its value has become obvious to me even though I'm not following the XUnit approach (I'm writing the tests after coding). I've already found several minor bugs and I can see how much more effective it would have been to be writing the tests at the same time as writing the code. By putting a structure around test case generation the XUnit approach makes it much easier to be more thorough in your testing. In the past I've typically written simple test harnesses as required but in a fairly casual way without a consistent mechanism for running the tests. They are usually not capable of being run automatically so tend to be run only sporadically.

I've just noticed that there is a COMUnit project. Since most of my day-to-day work is currently COM-based development this may also be worth investigating.

I got this error recently when experimenting with .NET/COM interop:

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

Never having seen this before when making COM calls it fooled me into thinking it was some .NET interop related problem. The actual problem was passing the wrong interface IID in a QI call - _HelloWorld instead of IHelloWorld in this code:

CComPtr<IHelloWorld> spHelloWorld;
hr = varDisp.pdispVal->QueryInterface(__uuidof(_HelloWorld), (void**)&spHelloWorld);

I've made this mistake before but only remember getting access violation type errors. Anyway this unsafe QI call is unnecessary these days. The IUnknown struct definition in unknwn.h provides this safe templatized call:

template<class Q>
HRESULT STDMETHODCALLTYPE QueryInterface(Q** pp)
{
  return QueryInterface(__uuidof(Q), (void **)pp);
}

... so the QI in the code above should have been:

hr = varDisp.pdispVal->QueryInterface(&spHelloWorld);