Scott Hanselman

It's getting considerably easier to create and distribute Visual Studio Extensions.  With Visual Studio 2008, you can find extensions at the Visual Studio Gallery. There's also a very good VSX (Visual Studio Extensibility) Developer Center on MSDN that has a ridiculous amount of information on how to extend VS, and there are LOTS of great VS 2008 add-ins. The documentation is really well fleshed-out. It also includes info on the little-known, but totally awesome "VS Shell," but that's another post.

Visual Studio 2010 Beta 1 shows some new and interesting was to extend VS. One nice way to say it is "moving beyond add-ins." One example is that the Editor in VS2010 uses MEF (Managed Extensibility Framework) at its heart. It also uses Immutable Text Snapshots that make accessing the buffer from other threads easier. I talked to Noah Richards, one of the devs on the editor, in a recent episode of my podcast.

Terry Clancy points out how much easier it is. Seriously, the post is of epic length, check it out.

For the Visual Studio 2010 Shell, we’ve made targeted investments to the developer experience:

· No more complicated load keys! - Developers are no longer required to procure a Package Load Key (PLK) or a Shell Load Key (SLK) to develop Visual Studio 2010 Shell applications!

· No requirement for Registry. Packages can now be installed without requiring developers to update configuration settings in the Windows registry.  In many cases, this means that packages can now be x-copy deployed.

· Easier, more robust deployment – The redistributable shell installers have been updated to support Windows Installer source caching features, thus is during a repair, user’s won’t be required to point MSI to the original installation file or media.

· Improved SDK tooling – New templates have been added to make it easier to get started with the Visual Studio Shell, and create common types of extensions.  For Visual Studio Shell (Isolated Mode) developers, we’ve significantly improved performance of our F5 Debugging experience.

So what does a VS2010 extension look like?

Installing a VS2010 Extension with the Online Gallery and Extension Manager

Doing my talk on .NET 4 at TechEd this year, I got to use a new extension from the folks at Clarius Consulting called the Demo Dashboard. The idea is that while you're giving a talk at a conference like TechEd, the audience is using Twitter and a hash-tag that you set (I used #scottha) to give you real time feedback on your presentation. They can tell you if you're doing a good job, if your fonts are the right size, your speed, and they'll also give you a headcount of twitter users in your talk.

The code for the Demo Dashboard is up at Codeplex under Ms-PL while the extension itself is at the VS Gallery. It's actually a VS extension WITH extensions of it's own!

The plugin integrates with the Editor and hangs around (it can be collapsed) while you're giving your talk. For my talk, I used a debug build and just dropped it into the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Components folder.

However, you can just go to the Extensions Manager and download it directly into Visual Studio:

If you download it manually from a website like the Visuals Studio Gallery, you'll notice the VSIX extension is associated with Visual Studio:

You'll be warned that 'VSLauncher' is trying to run something, and if you accept it, the VSIXInstaller will do its thing. It's easier to just do it from inside the Extension Manager in Visual Studio.

The Demo Dashboard is entirely written in managed code and is actually a WPF app. Notice in this screenshot of the main XAML file that the plugin is actually running inside the WPF editor at the bottom of the split-screen view.

They Demo Dashboard folks created a whole sub-plugin model you can use to extend this dashboard for your own conference. Using MEF (now built into .NET 4), they're pulling in a Twitter Service, and having Widget DLLs provide one or more widgets.

namespace CoolnessWidget
{
    [Export(typeof(IWidgetProvider))]
    [Widget(Name = "Cool Widget", After = "Font Size Widget")]
    internal class CoolWidgetProvider : IWidgetProvider
    {
        IEnumerable<IWidget> IWidgetProvider.GetWidgets(Context context)
        {
            // creates an instance of our widget providing it the core context and twitter service to work with
            CoolWidget widget = new CoolWidget(context, this.TwitterService);
            return new List<IWidget> { widget };
        }

        [Import]
        private TwitterService TwitterService { get; set; }
    }
}

There's a lot of great examples in the code on clever ways to use MEF to make consumption of services easier by plugins. The WidgetManager class brings together a bunch or "hard to deal with" classes, then Exports them via MEF to make consumption easier by other classes and plugins downstream.

I think, however that it could be even MEFier. Remember, it's Ms-PL, and a CodePlex project, and there's a lot of TODO:'s marked in the comments, do we're free to change and improve the code. Go check it out.

Related Links

• Demo Dashboard on Codeplex
• Visual Studio Gallery
• MSDN Docs - Extending the Visual Studio Environment
• Learn How to Extend Visual Studio
• Quan To's VS Extensibility Blog
• VS 2010 Card Game Starter Kit
• Wiki Classifier
• Terry Clancy on VSIP and VS2010

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

UPDATE: There is a new modern open source alternative to Fusion Log Viewer called Fusion you should check out!

It's time to remind people about Fusion. Mostly because I don't see as many people using it as should. I mentioned it as long as six (!) years ago and it's still useful. I used it just this week with .NET 4.

Sometimes when an assembly doesn't load, there's still a sense/feeling that "something in the black box has broken." For some folks, the black box is larger and obscures more, than for others. My point is, if you know where to look, there is no box at all.

When it comes to assemblies there's three "times" to know about:

• Binding before it happens - What do you want?
  • ILDASM or Reflector will tell you what your assembly wants (what it was compiled against)
• Binding as it happens - Where does it look?
  • Fusion (the Assembly Binding Log Viewer) will show you all assembly binds if you set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1
• Binding after it happens - What did you get?
  • Process Explorer will tell you what DLL (assembly) is loaded in memory and from where it came.

Here's an example of how a tiny bit of digging saved me hours of confusion recently when I hit an unusual edge case. I was doing a build of sample that was showing C# interop-ing with IronPython, but I was using a daily build of .NET 4 and a random build of IronPython.

I made a mistake and had some really old DLLs floating around that I shouldn't have had. My symptom was a FileNotFoundException for the file "System.Dynamic.dll." I KNEW it was in the GAC (Global Assembly Cache) and I could SEE it as a reference DLL in my directory. Can't find the file? Dude, it's right there!

Turning on Fusion Logging

You probably have a tool to help on your development system already. Type "Fusion" in the Start Menu. The Assembly Binding Log Viewer, or "Fusion Log Viewer" will tell the CLR to load assembling binding/loading activities to a folder, then let you see them.

Be sure to run it as Administrator if you want to change the Settings, otherwise they'll be grayed out.

Alternatively, just set the Registry keys your self. (I just memorized them, as I set them all the time.) Set HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1 and HKLM\Software\Microsoft\Fusion\LogPath registry value to C:\FusionLogs or some path that exists.

Personally, I leave this on all the time on my dev machines (there's a small speed hit) and just clean the folder out every once in a while.

Solving My Binding Problem

Once I turned on Fusion Logging I could immediately see a failure in my folder:

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified. 

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.xxxxx\clr.dll
Running under executable  C:\Users\Scott\Desktop\TechEd09\FX4\Demo 5 - DLR\Two.IronPythonInterop\bin\Debug\Two.IronPythonInterop.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = HANSELMAN-DEV10\Scott
LOG: DisplayName = System.Dynamic, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
LOG: Appbase = file:///C:/Users/Scott/Desktop/TechEd09/FX4/Demo 5 - DLR/Two.IronPythonInterop/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Two.IronPythonInterop.exe
Calling assembly : IronPython, Version=2.6.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.xxxxx\config\machine.config.
LOG: Post-policy reference: System.Dynamic, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Users/Scott/Desktop/TechEd09/FX4/Demo 5 - DLR/Two.IronPythonInterop/bin/Debug/System.Dynamic.DLL.
LOG: Attempting download of new URL file:///C:/Users/Scott/Desktop/TechEd09/FX4/Demo 5 - DLR/Two.IronPythonInterop/bin/Debug/System.Dynamic/System.Dynamic.DLL.
LOG: Attempting download of new URL file:///C:/Users/Scott/Desktop/TechEd09/FX4/Demo 5 - DLR/Two.IronPythonInterop/bin/Debug/System.Dynamic.EXE.
LOG: Attempting download of new URL file:///C:/Users/Scott/Desktop/TechEd09/FX4/Demo 5 - DLR/Two.IronPythonInterop/bin/Debug/System.Dynamic/System.Dynamic.EXE.
LOG: All probing URLs attempted and failed. 

You can see that it's looking all over for the file, first in the GAC< then all over the local folders before it gives up. Hm. Why isn't this working? I can see the file sitting right there.

Well, what's the public key token for this signed assembly? I can run "sn -T" on the file:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0>
sn -T System.Dynamic.dll 

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.xxxxx.1
Copyright (c) Microsoft Corporation.  All rights reserved. 

Public key token is b03f5f7f11d50a3a

Wha? What's b03whatever? That's not b77whatever like the one my app is looking for! Looks like my sample app had reference not only an old version of System.Dynamic, but one with a completely different public key. That's what I get for not cleaning out my obj directories between daily builds.

This could have been just by setting the registry keys and watching the c:\fusionlogs folder, but the Fusion Log Viewer makes the process more user-friendly.

If you're debugging version number mismatches or strong-name mismatches, Fusion will ALWAYS tell you what's really going on. There is no Black Box.

Related Links

• Detailing Failed Assembly Loads with the Assembly Binding Log Viewer ("The Fusion Logger")
• More on Assembly Binding, Strong Naming, the GAC, Publisher Policy and Dynamically Loaded Assemblies
• Gotcha in .NET Framework handling of Versions and Publisher Policies
• Be aware of your DLLs and who's loading them - know about assembly binding redirects
• Richard Grimes' most excellent .NET Fusion Workshop

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I've posted twice so far on .NET 4, first on ASP.NET 4, then on improvements in C# around dynamism and PIAs as well as the COM Binder. Now "dynamic."

So I asked this guy, what's up with the dynamic keyword, and what type was it exactly? I mean, C# isn't dynamic, right? He says:

"Oh, well it's statically-typed as a dynamic type."

Then my brain exploded and began to leak out my ears. Honestly, though, it took a second. Here's a good example from some of Ander's slides:

Calculator calc = GetCalculator();
int sum = calc.Add(10, 20);

That's the creation of an object, invokation of a method, and the collection of a return value. This is the exact same code, as the "var" type is figured out at compile time.

var calc = GetCalculator();
int sum = calc.Add(10, 20);

If you wanted to do the exact same thing, except with Reflection (like if it were some other class, maybe old-COM interop, or something where the compiler didn't know a priori that Add() was available, etc) you'd do this:

object calc = GetCalculator();
Type calcType = calc.GetType();
object res = calcType.InvokeMember("Add",
    BindingFlags.InvokeMethod, null,
    new object[] { 10, 20 });
int sum = Convert.ToInt32(res);

It's pretty horrible to look at, of course. If the object is some dynamic thing (from any number of sources), we can do this:

dynamic calc = GetCalculator();
int sum = calc.Add(10, 20);

And get the dynamic method invocation and conversion of the return type. Basically it looks just like we're calling any other object.

Dynamism?

Here's the differences you see while coding. Hovering over the keyword gives me this nice tooltip.

When I hit the "." expecting intellisense to save me from my ignorance:

I'm told this is a dynamic expression that will be resolved at runtime.

Here's a C# program calling a method in a python (.py) file:

ScriptRuntime py = Python.CreateRuntime();
dynamic random = py.UseFile("random.py");

//Make an array of numbers
var items = Enumerable.Range(1, 7).ToArray();

random.shuffle(items);

Here we're passing in an array if ints (System.Int32[]) into the Python 'shuffle' method and it works just fine.

The DLR basically enables everyone to talk to everyone. That includes not just Python and Ruby, but Silverlight, Office/COM, and others.

What price REPL?

John Lam has a great post about his TechEd talk where he took a spin on a traditional REPL (READ-EVAL-PRINT-LOOP) using the DLR. He even allows switching back and forth between languages, which is odd/interesting.

John's even put the code for his REPL up on GitHub. Why is this interesting? Well...

He took his REPL and embedded it into an example Open Source app, specifically Witty, a WPF Twitter Client. Why he didn't use BabySmash is beyond me. ;) Check it out, as well as the source code diff for Witty on John's blog.

It'll be nice to have this kind of dynamic stuff just baked in and waiting for me to use it.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

I really advocate folks reading as much source as they can because you become a better writer by reading as much as writing. That's the whole point of the Weekly Source Code - reading code to be a better developer.

Reading code in Open Source projects is a good way to learn, especially if the project has been around a while and been successful, or if you already respect the team of people working on it. Less reliably, you can find snippets of code by searching and sharing code.

Tree Trim == CleanSources++

Many years ago, Omar Shahine wrote a great little app called Clean Sources. It added a right-click menu to the Windows Explorer that would delete your bin, obj and setup folders.

Later, Jeff wrote Clean Sources Plus. It added a "Clean and Zip" option as well as support for removing source control bindings.

Now, Steve Dunn has extended these to create Tree Trim, a command-line tool to do all this and more. He's extended it to include a plugin model that creates a little pipeline of plugins. You can chain them together and extend the command-line with your own plugins, and MEF (Managed Extensibility Framework) is at its core.

Tree Trim is convenient for build servers where you want to, for example, make a working copy, delete source control bindings, zip stuff up, email it, etc.

Each command line argument is a "task" and each command line arg (moniker) maps to a object.

treetrim.console.exe c:\dev\myproject -workingCopy -deleteFromDisk -zip -email

It's significant that order of arguments matter, so the args cause the plugins to run in order, like "make working copy, delete bin/obj, zip up, email."

Make your own Plugin and be MEFy

He's got an IPlugin interface:

public interface IPlugin
{
    string Moniker { get ; }
    string WorkingPath { get ; }
    void Cleanup( ) ;
    void Run(IPluginRuntimeSettings settings, IPlugin lastPlugin);
}

When you make a plugin, you need to let MEF know that it's available by Exporting the type:

[Export(typeof(IPlugin))]
public class SomePlugin : IPlugin
{
   ...
   public string Moniker
   {
      get { return @"newPluginArgument" ; }
   }
   ...
}

Then any plugin in the same directory gets pulled into a list of plugins...

public DiscoverPluginsInAssemblyDirectory( )
{

    var catalog = new DirectoryCatalog(disk.DirectoryOfExecutingAssembly);

    var container = new CompositionContainer(catalog);

    var batch = new CompositionBatch();
    batch.AddPart(this);

    container.Compose(batch);
}

[Import( typeof( IPlugin ) )]
public IList<IPlugin> Plugins
{
    get;
    set;
}

The app kicks off this little pipeline by passing the command line args in along with the plugins found:

Trimmer.TrimTree(
   new TaskCollection( pluginDiscoverer.DiscoveredPlugins, commandLineArgs ),
   path );

...then...

public static void TrimTree(ITaskCollection tasks, string sourceTreeRoot)
{
    ITask lastTask = new Task { Plugin = new NullPlugin( sourceTreeRoot ) } ;

    foreach ( ITask eachTask in tasks )
    {
        eachTask.Run( lastTask );
        
        lastTask = eachTask ;
    }

    IEnumerable<ITask> reversedTasks = tasks.Reverse( ) ;

    foreach (ITask eachTask in reversedTasks)
    {
        eachTask.Cleanup();
    }
}

The code is actually very easy to read and is up at TreeTrim on Google Code and check out the FAQ. Plugins are super easy with MEF and Tree Trim has some good examples of a number of things. First, just plugins in general, but also a technique for passing settings to plugins.

Add Context Menus to Explorer

You can easily create context menus in Explorer for this tool (or any tool). Add a Key to the Registry like below.

HKEY_CLASSES_ROOT\Folder\shell\<WHATEVER TEXT YOU WANT>\command

Then in the (Default) string value, put it something like this (for example):

"C:\Program Files (x86)\Tree Trim\TreeTrim.Gui.exe" "%1"  -workingcopy -deletefromdisk -zip:writeTo:"c:\users\scott\desktop\justzipped.zip"+dontCleanUp

Here's how it looks in registry:

Steve is also starting to setup tests using XUnit. He's starting to use the ContextSpecification Pattern for his tests, so it'll be interesting to see if he completes the tests. That part is pretty basic so far. Check out the TaskCollectionSpecs.cs as an example.

All in all, fun to read, and an interesting tool I'll use to quickly clean and send code samples around. I may extend it with a plugin to upload to my blog, then put the link in the clipboard. That could make blogging samples easier.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By

Just got a great tweet from Jeremiah Morrill about .NET 4.

I love a challenge! In my first Whirlwind Tour post on ASP I mentioned how COM Interop and Office Interop was fun with 4.

I've done a lot of COM Interop with C# and a LOT of Office Automation. Once upon a time, I worked at a company called Chrome Data, and we created a Fax Server with a Digiboard. Folks would call into a number, and the person who took the order would pick the make/model/style/year of the car and "instantly" fax a complete report about the vehicle. It used VB3, SQL Server 4.21 and Word 6.0 and a magical thing called "OLE Automation."

Fast forward 15 years and I sent an email to Mads Torgerson, a PM on C# that said:

I’m doing a sample for a friend where I’m simply spinning through an Automation API over a Word Doc to get and change some CustomDocumentProperties.

I’m really surprised at how current C# sucks at this. Of course, it makes sense, given all the IDispatch code in Word, but still. Dim != var as they say. Fix it!

Well, everything except "fix it!" is true. I added that just now. ;) I did a post on this a while back showing how scary the C# code was. This is/was somewhere where Visual Basic truly excels. I vowed to only use VB for Office Automation code after this fiasco.

If you want to melt your brain, check out the old code. No joke. I've collapsed the block because it's too scary. See the "ref missings"? The reflection? The Get/Sets? Scandalous!

{
  ApplicationClass WordApp = new ApplicationClass();
  WordApp.Visible = true;
  object missing = System.Reflection.Missing.Value;
  object readOnly = false;
  object isVisible = true;
  object fileName = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\NewTest.doc");
  Microsoft.Office.Interop.Word.Document aDoc = WordApp.Documents.Open(
      ref fileName,ref missing,ref readOnly,ref missing,
      ref missing,ref missing,ref missing,ref missing,
      ref missing,ref missing,ref missing,ref isVisible,
      ref missing,ref missing,ref missing,ref missing);

  aDoc.Activate();

  string propertyValue = GetCustomPropertyValue(aDoc, "CustomProperty1");
  SetCustomPropertyValue(aDoc, "CustomProperty1", "Hanselman");

  foreach (Range r in aDoc.StoryRanges)
  {
     r.Fields.Update();
  }
}

public string GetCustomPropertyValue(Document doc, string propertyName)
{
  object oDocCustomProps = doc.CustomDocumentProperties;
  Type typeDocCustomProps = oDocCustomProps.GetType();
  object oCustomProp = typeDocCustomProps.InvokeMember("Item",
        BindingFlags.Default |
        BindingFlags.GetProperty,
        null, oDocCustomProps,
        new object[] { propertyName });

  Type typePropertyValue = oCustomProp.GetType();
  string propertyValue = typePropertyValue.InvokeMember("Value",
       BindingFlags.Default |
      BindingFlags.GetProperty,
      null, oCustomProp,
      new object[] { }).ToString();

  return propertyValue;
}

public void SetCustomPropertyValue(Document doc, string propertyName, string propertyValue)
{
  object oDocCustomProps = doc.CustomDocumentProperties;
  Type typeDocCustomProps = oDocCustomProps.GetType();
  typeDocCustomProps.InvokeMember("Item",
        BindingFlags.Default |
        BindingFlags.SetProperty,
        null, oDocCustomProps,
        new object[] { propertyName, propertyValue });
}

Fast forward to C# under .NET 4.

var WordApp = new ApplicationClass();
WordApp.Visible = true;
string fileName = @"NewTest.doc";
Document aDoc = WordApp.Documents.Open(fileName, ReadOnly: true, Visible: true);
aDoc.Activate();

string propertyValue = aDoc.CustomDocumentProperties["FISHORTNAME"].Value;
aDoc.CustomDocumentProperties["FISHORTNAME"].Value = "HanselBank";
string newPropertyValue = aDoc.CustomDocumentProperties["FISHORTNAME"].Value

foreach (Range r in aDoc.StoryRanges)
{
   foreach (Field b in r.Fields)
   {
      b.Update();
   }
}

See how all the crap that was originally reflection gets dispatched dynamically? But that's not even that great an example.

Word and Excel Automation with C# 4

That's just an example from Jonathan Carter and Jason Olson that gets running processes (using LINQ, woot) then makes a chart in Excel, then puts the chart in Word.

using System;
using System.Diagnostics;
using System.Linq;
using Excel = Microsoft.Office.Interop.Excel;
using Word = Microsoft.Office.Interop.Word;

namespace One.SimplifyingYourCodeWithCSharp
{
    class Program
    {
        static void Main(string[] args)
        {
            GenerateChart(copyToWord: true);
        }

        static void GenerateChart(bool copyToWord = false)
        {
            var excel = new Excel.Application();
            excel.Visible = true;
            excel.Workbooks.Add();

            excel.get_Range("A1").Value2 = "Process Name";
            excel.get_Range("B1").Value2 = "Memory Usage";

            var processes = Process.GetProcesses()
                                        .OrderByDescending(p => p.WorkingSet64)
                                        .Take(10);
            int i = 2;
            foreach (var p in processes)
            {
                excel.get_Range("A" + i).Value2 = p.ProcessName;
                excel.get_Range("B" + i).Value2 = p.WorkingSet64;
                i++;
            }

            Excel.Range range = excel.get_Range("A1");
            Excel.Chart chart = (Excel.Chart)excel.ActiveWorkbook.Charts.Add(
                After: excel.ActiveSheet);

            chart.ChartWizard(Source: range.CurrentRegion,
                Title: "Memory Usage in " + Environment.MachineName);

            chart.ChartStyle = 45;
            chart.CopyPicture(Excel.XlPictureAppearance.xlScreen,
                Excel.XlCopyPictureFormat.xlBitmap,
                Excel.XlPictureAppearance.xlScreen);

            if (copyToWord)
            {
                var word = new Word.Application();
                word.Visible = true;
                word.Documents.Add();

                word.Selection.Paste();
            }
        }
    }
}

Notice the named parameters in C#, like 'Title: "whatever"' and "copyToWord: true"?

PIAs no long stand for Pain in the *ss - Type Equivalence and Embedded Interop Assemblies

Primary Interop Assemblies are .NET assemblies that bridge the gap between a .NET app and a COM server. They are also a PIA, ahem. When there's articles about your technology on the web called "Common Pitfalls With ______" you know there's trouble.

Typically you reference these Interop assemblies in Visual Studio and they show up, predictably, as references in your assembly. Here's a screenshot with the project on the right, and the assembly under Reflector on the left.

This means that those PIAs better be deployed on the end user's machine. Some PIAs can be as large as 20 megs or more! That's because for each COM interface, struct, enum, etc, there is a managed equivalent for marshalling data. That sucks, especially if I just want to make a chart and I'm not using any other types. It's great that Office has thousands of types, but don't make me carry them all around.

However, now I can click on Properties for these references and click Embed Interop Types = true. Now, check the screenshot. The references are gone and new types have appeared.

Just the types I was using are now embedded within my application. However, since the types are equivalent, the runtime handles this fact and we don't have to do anything.

This all adds up to Office and COM Interop that is actually fun to do. Ok, maybe not fun, but better than a really bad paper cut. Huh, Jeremiah? ;)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By