Imports designer 101

Oh, the imports designer. This innocuous looking piece of UI packs a lot of functionality in a little designer. You would think that this designer should be pretty straightforward. The original concept of this feature was that this would simply be the place to manage namespaces, much in the same way you would manage using statements or imports statements. You add a namespace to the designer, and then you can use the short name of types in that namespace in expressions. The Imports designer does indeed behave that way. However, if that’s all there was to it, I wouldn’t be writing this post, so let’s dive a bit deeper into the internals in Q&A format.

Q: Why is it called the Imports Designer?
A: Imports is the VB equivalent of the C# using statement. Since we use VB expressions, we decided to take the VB name for consistency.

Q: Why are there so many namespaces in the Imports Designer? I would never use that many namespaces in a regular C# or VB project.
A: The list of namespaces is populated by the VisualBasicSettings in the XAML, and all of the CLR namespaces are displayed in the Imports designer.

Q: Why are all those namespaces serialized?
A: If you view the XAML and look at the namespaces in the VisualBasicSettings, you will see that there are two types of namespaces serialized: XML namespace names (contains URI) and CLR namespaces (contains namespace/assembly pair). The XML namespaces are self-explanatory. The CLR namespaces are used in two ways:

1. To load assemblies used by hosted compiler when validating the root activity of the workflow at design time and runtime.
2. To pass the list of namespace strings as import statements to hostable editor.

Q: No really, why are all those namespace/assembly pairs serialized? Why doesn’t the hosted compiler simply use the list of referenced assemblies in the project to load assemblies?
A: The list of references saved in the *.csproj or *.vbproj files is not available at runtime. Workflows are not necessarily compiled before execution. Because you can execute a single, standalone XAML file, the list of all assemblies (including dependent assemblies) must be serialized.

Q: OK, so they need to be serialized, but that’s a really long default list of namespaces and assemblies. Why do the hosted compiler and hostable editor need all of this stuff?
A: Some of the namespaces we provide in our default project templates as convenience features. For example, the Microsoft.VisualBasic namespace is supplied so that you can use VB constants (such as vbCrLf for a newline character) without having to do anything special. System.Linq is required for writing expressions that use Linq. Some, like System.Data, System.Text, System.Collections.Generic, System just make sense to have since types in these namespaces are frequently used in expressions. And then there are the others that contain references to assemblies needed for the compiler and the validation service to do its work, notably the Microsoft.VisualBasic.Activities (contains hosted compiler) and System.Activities.Debugger (for debugging).

Q: I noticed that namespaces randomly appear sometimes in the Imports designer. Why?
A: When an expression is compiled in a workflow in the Visual Studio project system environment, the union of the list of referenced assemblies and the list of assemblies in the VisualBasicSettings are passed to the hosted compiler. The compiler then goes ahead and compiles the expression, and for valid expression spits out the list of namespace/assembly pairs used in the expression. This list can contain namespace/assembly pairs that were not previously serialized in the VisualBasicSettings, so these new pairs are serialized and a new namespace magically appears in the Imports designer.

Q: Why can’t I delete namespaces (unless they are invalid) in the Imports designer?
A: CLR namespaces are serialized as namespace/assembly pairs. By deleting a namespace, you might accidentally delete the last reference to an assembly, which can result in accidentally invalidating expressions using fully qualified names.

Q: Why do namespaces show as invalid sometimes?
A: This happens when your project does not contain a reference to the assembly that contains the namespace. You are allowed to delete these namespaces because it is assumed that you don’t need the assembly any more.

Q: Why doesn’t System.Activities.Presentation appear in the Imports designer when there is a CLR namespace for it in the VisualBasicSettings?
A: There is no reference to System.Activities.Presentation (we don’t need one), so we don’t show it. Also, there’s nothing in System.Activities.Presentation that should be used in expressions anyway, so it’s not a big deal.

That’s the high level detail. There’s a couple more tidbits in the deck on expression editing I previously posted, check out slides 13-17.