By Popular Demand [Jack Gudenkauf]

We saved the best for last!

Jack Gudenkauf (JackG) WebLog — Fri, 27 Jul 2007 23:06:17 GMT

VS 2008 and .Net 3.5 Beta 2 (code name "Orcas") is now available. Here is the link to download . I am

re: By Popular Demand [Jack Gudenkauf]

Ian Duncanson — Tue, 31 Jul 2007 06:13:19 GMT

Jack,

Does the UI Extensibility mechanism also extend to Cross-Process isolation, or is it restricted to Cross-AppDomain?

Regards,

Ian

re: By Popular Demand [Jack Gudenkauf]

Kevin — Tue, 31 Jul 2007 17:11:35 GMT

This new AddIn model is the best thing since sliced bread. However, what if a developer wants to completely break the rules the model has specified? Are there any compile/runtime restraints?

For example, we must do a major software integration between two applications. We would love to use the AddIn model, but I have read the rules that developers should follow when using this model, and unfortunately our requirements force us into breaking those rules. We will have a semi-tight integration between these two applications, and that is fine we accept the consequences, but what are the limits of the AddIn model you have designed?

Will it allow forms to be passed around?

Will it allow non-serializable classes to be passed around?

Will it allow any object to be passed around?

If these are allowed (if the addin is in the same appdomain as the host), what are the consequences? Is the only downside is loss of independent versioning? If so that is good to know. At least the AddIn model will save us a lot of work of managing addins.

Remember, there will be many consumers of your framework that do not use it as intended, but you already knew that :)

PS: I tried passing a form from an addin to the host (even from a different process) and it worked, the form was displayed. I was very surprised that worked. Is doing such a thing safe to do? (Safe as in will not crash the application provided no .NET rules are broken)

re: By Popular Demand [Jack Gudenkauf]

JackG — Wed, 01 Aug 2007 00:47:52 GMT

Cross Process WPF is currently unsupported in Beta2. We are looking into it.

Kevin, aside from versioning issues you lose unloadability unless you load in a seperate AppDomain.

We do not enforce contract constraints in the Run Time. So you can "violate" the guidance.

As you mention, you can use the initial discovery and activation and forgo some of the constraints in your OM. Keep in mind that you will be leaking types however.

We would love to hear from others about the value of forms extensibility.

- JackG

re: By Popular Demand [Jack Gudenkauf]

Kevin — Wed, 01 Aug 2007 16:35:17 GMT

JackG,

Thanks for the information. Here is some feedback: image an Office 2007 application like Word such that an AddIn adds an entire new tab and replaces (or hides) Word's canvas with the AddIn's when the tab is selected. Like an application inside an application.

For us,

Unloadability is not required.

Versioning is not required (initially at least until a lot of refactoring is performed)

Sometimes requirements force people into breaking best practices. It is important for developers and architects to understand the consequences of their design decisions, especially when guidelines are broken.

I anticipate many consumers of your AddIn model to not use it exactly as it was designed (due to how useful and powerful it is). Perhaps a blog post someday about what happens when people bend/break the rules would be good?

Thanks,

Kevin

re: By Popular Demand [Jack Gudenkauf]

CLR Add-In Team — Wed, 01 Aug 2007 23:09:31 GMT

Kevin, Thanks for the feedback.

The primary guidance I give to customers is design for Unloadability, Isolation, Versioning, Sandboxing, etc.. now.

If you decide you do not need all the functionality or you do not take advantage of something like versioning in v1 then there is no adverse side effects.

Arguably, complexity is a side effect but that’s what we get paid to understand.

If however, you do not design for these features, it is extremely unlikely that you can add them later (i.e., at least without a breaking change or worse, a loss of business).

You can always build on our model and still run in the Hosts default AppDomain and thus the same security context. Or optimize around clumping like (i.e., Same lifetime and security context) Add-in’s in the same AppDomain.

If you do not Marshal, you do not incur the performance overhead of the transition.

And you can always take advantage of our Direct Connect optimization feature.

As you point out there may be affordances for not strictly adhering to the model and this is precisely why we don’t enforce strict constraints at run time. We understand that there are always exceptions to the rule.

In your example of Office extensibility. The user decides what Add-in’s may be loaded. This also implies a need to unload them.

If an Add-in’s behavior causes the Host application to not perform, this is a huge problem for the user.

Imagine a 3rd party spell checker that is loaded automatically and causes the Host Word processor app to crash.

If the user (or Host – Office disables loading an ill behaved Add-in) cannot disable the spell checker or can’t readily recycle the process (i.e., to unload and not reload at start-up) they can’t even use the Word Processor due to an ill behaved Add-in.

You can also imagine that a user may not understand that the Add-in is causing the Host app to fail and thus blames the Host provider. Customer perception causes sales of the application to cease.

Isolation is a critical component for ensuring the Host is “protected” from the Add-in’s adverse behavior. And Add-in’s are protected from other ill-behaved Add-in’s. As an example, do a quick search on Office Add-in’s where people ReleaseCOMObject in a loop (yikes).

Isolation also enables Add-in’s to run in a different security context than the Host.

Regarding versioning. In your example, imagine a 3rd party offering your tab form feature. If your customer relies on this feature and you release version two of your host without providing compatibility with the Add-in, then the user will be locked into your version one product release and you will not be able to sell upgrades to your product.

In the end, software engineering is in support of the business. - JackG

re: By Popular Demand [Jack Gudenkauf]

Kevin — Thu, 02 Aug 2007 00:34:31 GMT

Fantastic information... I do not disagree with a single word you said. I follow that advice whenever possible, but you will see in my email to you (from your blog) why I have to break some rules initially.

Great post, I am sure anyone reading will find it valuable.

Thanks,

Kevin

re: By Popular Demand [Jack Gudenkauf]

Ian Duncanson — Thu, 02 Aug 2007 08:56:05 GMT

Jack,

Just wondering what mechanism (Load, LoadFrom, other) the System.Addin classes use to load Addins, and what if any "gotchas" there are with that chosen mechanism that we should be aware of.

Also (I know you may be guarded about a response here), you mentioned that you are looking into out-of-process visual addins in the future - are you looking into this for Orcas, or for a future release (again, realize you may not want to answer this, but thought it was worth a shot).

And a final question - does the visual WPF addins also permit hosting Winforms via crossbow (interop) in an addin?

Regards,

Ian

re: By Popular Demand [Jack Gudenkauf]

JackG — Thu, 16 Aug 2007 21:34:44 GMT

Ian, We load assemblies from disk and thus we use LoadFrom internaly. We handle all the gotchas for you. There are a number of things we have all experienced in rolling our own implementation of an add-in loader, including loader context issues, etc.. It is easy to get this wrong and this is why we delivered a robust loader for Add-in's.

I don't have any more information on OOP UI but watch this blog for any changes on the subject.

As far as Crossbow is concerned see my recent post/video (http://blogs.msdn.com/clraddins/archive/2007/08/15/video-jack-gudenkauf-on-the-bcl-and-add-ins-jack-gudenkauf.aspx). - JackG

re: By Popular Demand [Jack Gudenkauf]

zzz — Fri, 17 Aug 2007 14:42:25 GMT

What kind of performance implications there are using full vs direct connect and otherwise?

In far future, suppose we can have the GC run on another core cleaning the garbage without interrupting program execution and thus give means to write an audio application in C#. Now I could want to make it possible to have users to create managed audio signal processing plugins passing some data back and forth quickly as possible to not add too much latency. Is this kind of thing completely unimaginable for the AddIn model or is there a way to do this type of large buffer passing with close to zero overhead? Or can you share a memory section with the addin without creating a need to give it higher priveleges.

re: By Popular Demand [Jack Gudenkauf]

CLR Add-In Team — Fri, 17 Aug 2007 19:36:34 GMT

DirectConnect only works when there is no isolation boundary between the host and the add-in. You won't get any of the benifits of isolation but at the same time you don't pay the cost of crossing the boundary.

We've designed the model with performance in mind and made sure that we didn't add any measurable overhead to the cost of crossing a given isolation boundary. That said you of course will still have to pay that cost.

The best way to minimize the performance cost of crossing an AppDomain boundary is to design "chunky" rather than "chatty" interfaces. This is because there is mostly a fixed cost for crossing the boundary regardless of how much data you pass across. We've done performance tests and the cost of serializing a 100 MB byte[] across an AppDomain boundary was only about 20% greater than serializing a 1MB one. On our reference machine this came to .48 vs .4 seconds.

In your case it sounds like you don't need a terribly chatty interface and that the area of most concern is getting a large amount of sound data from the host to the add-in and back. You should always measure but if you are careful you will probably find that the amount of time the add-in spends processing the sound data will be much greater than the amount of time sending the data to it and returning it back.

--Jesse

re: By Popular Demand [Jack Gudenkauf]

Torgeir Fredriksen — Thu, 11 Oct 2007 23:36:43 GMT

Is it possible to use Add-In "UI extensibility" with traditional Winforms application (without WPF/Crossbow)? I am asking because we aim for using the 3.5 framework, but due to lack of 3rd party UI controls we want to stick with Winforms for now.

- Torgeir

re: By Popular Demand [Jack Gudenkauf]

Manny — Wed, 09 Jan 2008 20:49:34 GMT

Hi,

I've been playing around with the Calculator application (the one with the graphing parameters on it). I was interested to see if it was possible to create the AddIns in new processes or if not in a seperate appdomain but with a lower trust level.

I ran into trouble because I wasn't actually able to do either. However, after a little bit of playing around I realised I could do load visual addins in a seperate appdomain with lower trust settings providing I switched off the Zune theme on my computer!

Should I be able to create a visual addin in a different process?

Extensibility; Clients and Services calling each other

Jack Gudenkauf (JackG) WebLog — Mon, 10 Mar 2008 23:30:19 GMT

In this post I will be showing sample code (also found on our CodePlex site ) as well as an execution