Tom sent me a link to Jonathan Wells’ blog entry about the .netcpu:

.netcpu Corporation’s new ‘.NET’ Embedded development kit includes a .netcpu CPU Module, a general purpose microcontroller for programming embedded solutions using C# and the Microsoft .NET Embedded CLR. Use the kit to experiment with projects such as low-power and sensor applications( eg data collection and logging sensor) or create a simple, smart embedded device (eg smart refridgerator, robot or home automation system).

Note the words “Embedded CLR“…i.e. I’m 99% sure this is the same CLR that powers the SPOT watch. Rick Rashid had something in his OOPSLA keynote about this SDK. You can order the .netcpu Starter Kit for $499 or just the CPU module for $199.

I think I need to update my xmas list…

Update: There’s a good technical article about the .NET Embedded on WindowsForDevices.

How about this for transparency?

The Microsoft ASP.NET v1.1 Membership Management Component Prototype contains classes that allow a developer to more easily authenticate users, authorize users, and store per-user property data in a user profile. The authentication feature validates and stores user credentials which a developer can use to manage user authentication on a web site. The authorization feature lets you treat groups of users as a unit by assigning users to roles such as manager, sales, member, and so on. Combined with ASP.NET’s built-in authorization functionality, Windows Shared Hosting developers have end-to-end support for maintaining user-to-role mappings and authorizing users based on this information. The profile feature enables you to provide users of your Web site with a custom experience. By defining and using profile properties, you can track any custom information your application requires, including user information and user preferences.

Important: The functionality provided by this component is a preliminary version of the Membership, Roles, and Profile functionality coming in ASP.NET 2.0 and will change in the final release of ASP.NET 2.0. This means that any ASP.NET v1.1 applications you develop using this component will need to be updated when you migrate to the final release of ASP.NET 2.0. This is also a non Microsoft supported component.

What I love about this the most is that it really reflects a change in mindset. In the past, I doubt we would have shipped this because it is likey to change before release. Personally, I like this approach – ship early and often and be honest about the quality and longevity. Sure, you have to deal with a few people who don’t read things like “will change“ or “not supported“ but the benefits outweigh the issues dramatically.

We interupt this blog’s coverage of OOPSLA with a quick observation & question related to development…

I’m hacking around writing a Word 2003 SmartTag in C# (more on the why later). I wanted my recognizer to be document-dependent – i.e. depending on some custom document properties, I wanted to change what gets recognized. A little digging reveils that there is no way (that I could find) to access the Word object model from the recognizer! The Recognize (and Recognize2) method receives strings as parameters, but it doesn’t receive an app-specific target object. This is unlike the Smart Tag Action‘s InvokeVerb (and InvokeVerb2) method which receives a Range object (from which you can navigate to the containing document, application and window) when running inside of Word. Bummer.

I think the reason for this is that the recognizer appears to run on a background thread while the action appears to run on the main app thread. Furthermore, both threads are STA apartment threaded, so if I can access the COM-based object model from the action thread, I can’t access it directly from the recognizer thread. I actually hacked up an add-in to provide the ActiveDocument to the recognizer thru a backchannel and it hangs Word on shutdown. I thought there might be an issue releasing the COM reference, but explicitly releasing it crashes the recognizer the next time it accesses the ActiveDocument.

So I’ve come to the conclusion that I somehow need to marshal this call from the background thread to the main app thread the action and addin are runing on (I did verify that both of those run on the same thread). The question is, what’s the best way to do that given that I’m writing this in C#? I thought I might use a system similar to Windows Form’s Control.Invoke(…), but it turns out that works by sending windows messages which isn’t particularly feasible for my problem. So now I’m thinking I have pass the ActiveDocument reference to the background thread using CoMarshalInterface. Or I might be able to use RemotingServices.Marshal() instead.

Anyone have any ideas? If so, leave a comment or drop me a line.

I’m sure this has made the rounds, but VPC 2004 SP1 is available. Among other updates, it has a new version of the VM Additions, which significantly improves the performance of XP SP2.

I may be at Strategic Architect Forum, but I’ve actually been coding off and on today - using WSE2 to expose web services. I hadn’t realized that SoapService supports auto generation of WSDL – pretty cool. I dug around with Reflector to figure out how it works. Turns out that SoapReceiver (parent of SoapService) exposes a method called GetDescription that returns the WSDL as an XmlDocument. The SoapReceiver version of GetDescription returns null, but the SoapService implementation uses an internal class called WsdlCreator to generate construct a ServiceDescription from SoapService type that you write. Pretty cool.

The only downside is that if you use raw SoapEnvelopes as the input and output parameter of the SoapService methods, the WsdlCreator has no way to know what schema to use for the corrisponding SOAP messages. So, it punts and represents a SoapEnvelope as sequence of xsd:any tags. 😦 If you use XML serializable types for parameters, then the WsdlCreator generates the associated schema in the WSDL. Only issue, I gave up on XML serialization a while ago.

I wish there was a way to adorn the SoapService methods with an attribute indicating the associated message schemas (with the ability to validate those messages automatically).