Anthony S. Kilhoffer

MS Surface Gotcha When Developing on x64 Platform

TonyKilhoffer — Tue, 22 Sep 2009 21:36:00 GMT

If you’re getting into MS Surface development and your development OS of choice is a x64 flavor of Windows Vista or Windows 7, there are several things to watch out for. Fortunately several people have already blogged about how to patch the SDK installer so you can install it on the x64 platform. Most of such blog posts, like Steve Robbins’ post also detail how to fix several executables so they will not automatically attempt to run under the x64 CLR. Steve also goes on to show you how to configure the build settings of the SDK samples so they are forced to run under the x86 CLR. If you followed everything Steve laid out, you should be good. If, like me, you create a new solution and start adding Surface apps to it and forget to alter the build configuration, you’ll run into a very un-intuitive snag.

If you don’t alter your build configuration for every Surface application you build as described in Steve’s blog post, your application will still compile, attach to the Surface Simulator, and even render your app as it should upon startup. But once it attempt’s to read input (a touch if you're on the actual Surface, a mouse click if you’re running under the Simulator), a NotImplementedException is thrown from within the bowels of the Microsoft.Surface.Common framework. NotImplementedException? WTF!? Yeah, that’s what I thought, too. That sort of exception usually comes from incomplete APIs being released with stubbed out methods. Not sure why it happens when the Surface app has attempted to run under the x64 CLR, but it happens and it’s not immediately apparent that it was your mistake. At any rate, save yourself some time profiling and beating your head against the monitor and refer to Steve’s article. He shows you how to alter the build configuration and target the x86 platform explicitly. There is no harm in deploying your application under these conditions, since all Surface machines are currently 32-bit Vista machines at heart.

Hope this saves someone some time. Happy Surfacing!

ASP.Net MVC RTM Gotcha

TonyKilhoffer — Fri, 20 Mar 2009 04:03:51 GMT

If you’re like me, you get so excited to check out the RTM of any piece of software you’ve spent the past several months (or more) evaluating, that you dismiss the release notes. Well, this time it cost me. I went to create a new view in Visual Studio, used the new wizard that allows you to strongly type the view, compiled, ran, and ouch! I received the following error:

Parser Error Message: Could not load type 'System.Web.Mvc.ViewPage<Reactor.Data.EventService>'.

Got to love informative ASP.Net exception pages. After doing some digging, I found that in my rush to get the RTM up and running, I overlooked a piece of information that was vital. Apparently, there is an additional configuration block that needs to be added to the web.config file. I’ll save you some trouble of reading the release notes. Add the following attributes to the “pages” element of your web.config:

pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"

pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"

userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">

Post build event for an entire solution in Visual Studio

TonyKilhoffer — Wed, 08 Oct 2008 21:00:00 GMT

While creating the SDK for Reactor, I ran into a need to execute an outside utility after building a solution in Visual Studio. The utility packages up all project outputs in a solution and prepares it for registration with a Reactor server. Obviously, post build events at the project level were not sufficient, and there is no post build event configuration in the VS solution properties. Google didn't produce any good results, either. So, I turned to my new favorite site for answers, stackoverflow.com. I asked the question, and in just minutes, I had the answer.

Basically, you have to handle the OnBuildDone event in a macro. I'm not a fan of VB syntax, but that's what we're limited to in the VS Macro Editor. Anyway, here is the code that was posted to the question on stackoverflow.com:

   1:  Public Sub AfterBuild(ByVal scope As vsBuildScope, ByVal action As vsBuildAction) Handles BuildEvents.OnBuildDone

   2:      If scope = vsBuildScope.vsBuildScopeSolution Then

   3:          System.Diagnostics.Process.Start("some file I want to run")

   4:      End If

   5:  End Sub

.csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; }

It works as advertised and saved me from coming up with some crazy hack. I can't take credit for this macro, and wish I knew who it was who answered the question on stackoverflow, but all I know is his/her username is Kyralessa. Thanks, Kyralessa!

Using the System.AddIn namespace to facilitate extensibility, Part Two

TonyKilhoffer — Wed, 08 Oct 2008 16:45:00 GMT

Part two of this multi-part series on the System.AddIn model focuses on the add-in pipeline. If you haven't read Part One, or you're not familiar with the System.AddIn model, you should read it before continuing.

Pipeline Overview

The add-in pipeline is a set of logical segments that the host and add in use to communicate with one another. I showed this diagram found on MSDN in Part One and here it is again. It's a good depiction of the pipeline and how each segment relates to another.

I'll describe each segment starting from the left (the host). Note that each segment is usually in its own .Net project. There are some optional exceptions, as I will detail later in this post, but for now just assume they are each a separate entity. Some types in the segments are required to be decorated with attributes found in the System.AddIn namespace. Those types are identified with the appropriate attribute type in square brackets ([example]) in the heading of each description.

Host

The host is the application that utilizes the add in to extend it's own functionality. It can be a Windows application, service, or another add in. It's responsible for discovering, activating, and managing the supported add ins.

Host view of add-ins

Although most of the MSDN documentation describes the host and add-in views as being abstract base classes, they can also be interfaces. Personally, I prefer the interface option, but your needs and preferences will likely vary. The host view represents the signature the host uses to communicate with the add-in.

Host side adapter [System.AddIn.Pipeline.HostAdapterAttribute]

For you design pattern enthusiasts, this is a classic example of the adapter pattern. It's purpose is to convert the types flowing from the host view to the contract segment. It contains no logic other than that necessary to copy a member from the view to the contract.

Contract [System.AddIn.Pipeline.AddInContractAttribute]

As it's name implies, this segment is the contract defined and agreed upon between the host and add-in. It must be an interface and it must implement the IContract interface itself.

Add-In side adapter [System.AddIn.Pipeline.AddInAdapterAttribute]

Just as it's host side counterpart converts the types flowing to the add in from its view, the add-in side adapter converts types from it's view to the contract.

Add-In view [System.AddIn.Pipeline.AddInBaseAttribute]

Again, just a mirror image of the host side view. It can be either an interface or abstract class, and it represents the signature the add-in uses to communicate with the host.

Add-In [System.AddIn.Pipeline.AddInAttribute]

Does this segment really need to be defined? Isn't the add-in the whole reason you're reading this?

Pipeline Development Considerations

You're probably thinking (all two of my loyal readers) of what a pain in the ass pipeline development must be. If you think of all the types you want to pass between the host and the add-in and consider each segment in the pipeline, you're looking at a lot of projects and a lot of plumbing. While that's true, there is some hope. Microsoft graced us with a Visual Studio add-in called the Pipeline Builder. You simply build the contract, and let the tool generate the additional projects for you. Huge time saver. When I started using the System.AddIn model, I didn't know about the tool. I wrote all the plumbing by hand and it was really daunting. Once I stumbled across the tool, however, it eased my pain considerably. I just wish they would have linked to the tool from the MSDN documentation so I would have found it sooner.

If you encounter a situation where you need to pass types that are not serializable between host and add-in, you'll need to take some additional steps. Types like these and collections of non-serializable types, need to have a full pipeline defined for it. You'll have to create a contract, views for both sides, and adapters. Again, with the help of the Pipeline Builder, it won't be too bad.

References

The following segments need the following references:

Contract: System.AddIn.dll, System.AddIn.Contract.dll
Add-in view: System.AddIn.dll
Add-in side adapter: System.AddIn.dll, System.AddIn.Contract.dll, Add-in view segment, Contract segment
Host side adapter: System.AddIn.dll, System.AddIn.Contract.dll, Host view segment, Contract segment
Host: System.AddIn.dll, Host view segment
Add-In: System.AddIn.dll, Add-in view segment

A note about the pipeline, and a very important one, is that when you set up references between the various segments, set the reference's "Copy Local" property to 'false'. If you don't, you're going to run into conflicts and it may take a while to figure out what went wrong. Such conflicts are not immediately obvious.

Directory structure

Your host will have to have a very specific directory structure defined for the add-ins. This very rigid structure is necessary for the framework to discover the add-ins and the various pipeline segment assemblies. The following diagram from MSDN shows what the structure should look like.

Earlier in the post, I mentioned some exceptions to the one project per segment rule. The host views of the add-in and the add-in views of the host can be combined into one assembly. The adapters can also be combined into one assembly, although this is only possible if you also combine the views into their own assembly. If you combine any of the mentioned types into their own assemblies, you have to deploy the assemblies to both sides of the pipeline. I have just been creating every segment in its own assembly so I don't have to remember these rules. Troubleshooting pipeline configuration can be tricky, so I try to keep it as simple as possible.

Closing

In the next part of this series, I'll demonstrate how to build the pipeline and alternatively, how to generate it automatically from a contract.

Using the System.AddIn namespace to facilitate extensibility.

TonyKilhoffer — Mon, 06 Oct 2008 20:54:00 GMT

If you've ever written a plug in framework for an application, you can appreciate how much work goes into managing the framework and the add ins it supports. The purpose of this post is to introduce you to the facilities contained in the .Net framework that make add in support much, much easier. First, let me identify some core concepts surrounding add in architectures. I'll try to keep these concepts platform and language neutral, since the need for application extensibility transcends platforms. Then, I'll show you how the classes in the System.AddIn namespace strive to meet them.

Note that when .Net 3.5 was in beta and the news of this add in framework was first released, it was referred to as the Managed AddIn Framework (MAF). Since it's release, however, the CLR team has been referring to it as simply the "System.AddIn model".

General Add In Core Concepts

Players

Add in models require two basic entities: the add in host and the add in itself. While both players are rather obvious, it's important to note that the host can take the form of an application, service, operating system, or even another add in.

The host is responsible for identifying supported add ins, activating them, and managing their lifetime. The add in itself is responsible for supplying additional functionality to it's host.

Discovery

Discovering available add ins is the first step to being able to use them. In a fully functional architecture, your host must be able to discover add ins and report on them without activating them. This allows you to selectively activate and deactivate add ins as the needs dictate.

Activation

In order to allow the add in to perform it's intended purpose, it must be activated. Activation includes creating an instance of the add in and turning over control to it. Your specific needs will dictate what level of isolation is required for your application.

Isolation

It would be a grave mistake to allow a hosted add in to affect the stability of the host, so isolation is, in my opinion, the most important concept involved in extensibility. It is vital that an add in be isolated from the rest of the application and only allowed to interact in the way the host designer intended.

The ultimate in isolation is running the add in out of process. That is, in it's own process. Due to performance restrictions, however, some architects prefer they are isolated in logical sandboxes or sub processes.

Lifetime Management

In most modern languages and platforms, the lifetime of objects is handled by the underlying runtime. This is a great benefit to developers, not having to worry about memory management. But in the case of add ins that are isolated from the hosting process, standard lifetime management isn't enough. Referential integrity must be maintained across process boundaries to ensure the references are not prematurely garbage collected.

System.AddIn Namespace

Now that we've identified some key areas of interest when considering add in architectures, let's see how the System.AddIn namespace strives to resolve them. First, I'll talk just a bit about about a few key classes you'll be using and the concept of the add in pipeline.

System.AddIn.Hosting.AddInStore is a static class that contains methods related to the physical storage and retrieval of add ins.

System.AddIn.Hosting.AddInToken is a class that represents an add in and its associated pipeline segments that can be activated.

The add in pipeline is a term used to refer to the pipeline of communication between the add in and its host. While creating and understanding the various segments can become complex, it's important to note that there is a tool called the Pipeline Builder that be used to generate some portions of the pipeline, making development and maintenance a bit easier.

The following diagram is a popular one to show the various pipeline segments and their relations.

I think the best explanation of each pipeline segment was best done in the MSDN documentation, which can be found here.

Discovery

As mentioned above, the AddInStore class contains methods that are used to manage the storage and retrieval of add ins. It discovers newly added add ins and maintains a cache summary of the available add ins. In short, discovery is nicely abstracted by the AddInStore methods, as long as you provide the correct base add in directory to the Update method.

Activation

Just as discovery was abstracted away for us, so is activation. The AddInTokens we've already discovered contain a generic method aptly named Activate that takes care of that for us. It's at this point that we specify our level of isolation and security by calling the proper overloaded version of said method.

Isolation

With the System.AddIn model, you have a few isolation options. You can activate an add in in an existing application domain, a new application domain, or an external process. As I mentioned in the core concepts section, your specific needs will dictate which level of isolation you'll choose.

If you're not familiar with what an application domain is, shame on you. It's a fundamental concept of the .Net framework and you should become familiar with it immediately.

As I mentioned under Activation in this section, you simply choose the proper overload of the AddInToken.Activate method that suits your needs. The framework takes care of the rest for you. This is one of the largest areas of benefit the System.AddIn model provides. Previous to this model, you had to manually spawn appdomains and/or processes and manage them yourself. It was a very cumbersome and sometimes tricky process.

Lifetime Management

The .Net garbage collector is not equipped to manage the lifetime of objects that are used across isolation boundaries. The logic involved in doing this is once again abstracted from us. The responsible classes use a combination of reference counting and remoting services to accomplish this. You have to do nothing to maintain the reference. Should you wish to terminate the reference and the add in instance at the add in side, there is a class called the AddInController that can help. It contains a Shutdown method that will free up references and resources for you.

In Closing

The System.AddIn model has helped me overcome many extensibility issues and it made it a pleasure doing so. I encourage anyone thinking of designing such an application to spend some time getting to know the model. It will save you a lot of time and a lot of heartache, I'm sure of it. If anyone runs into any limitations they are not able to overcome, I would like to hear about it. So far, it's done everything I've needed it to without a hitch.

The best documentation I've found is on MSDN and this location is a good starting place.