Freigeben über

By Popular Demand [Jack Gudenkauf]

  • Artikel

We just released VS 2008 and .Net 3.5 Beta 2 (code name "Orcas").

You may download the release here.

What’s new?

1. UI extensibility

By far the most requested feature has been UI extensibility built upon the Add-In model.

We are very happy to announce that we have delivered a solution!

We have added a Native Handle Contract (in System.AddIn.Contract) upon which, the WPF and CLR Add-In teams have built an implementation for enabling an application to Host WPF Add-In’s!

We will be posting more on the subject including a sample(s) showing isolated (i.e., Cross AppDomain) WPF Add-In’s.

Special Thanks to the WPF team for making this happen!

2. Direct Connect Optimization

We have provided an optimization to Add-In activation.

For Hosts and Add-in’s having the same view of each other (e.g., in V1) that forgo unloadability and share the same security context (i.e., run in the same AppDomain), you can choose to optimize the Add-In loading behavior (AddInToken.EnableDirectConnect) by not instantiating the Adapters.

3. Custom Qualification

We now support the ability to add a custom attribute (i.e., QualificationData) to your Add-In and/or Pipeline segments.

There are a number of clever things you could do with this ability. You could provide your own custom qualification logic for things such as Add-in’s that use this Attribute to inform you they qualify themselves as only running in the default AppDomain, etc…

The attribute data is available via the AddInToken.

4. Find Add-In

We have added a new method (AddInStore.FindAddIn()) that enables you to find an Add-In given a fully qualified path and type.

Among other uses, this feature allows you to forgo the demand for an Add-In Attribute used for Discovery.

This feature also supports scenarios where you may not know the Add-In location until Run Time (e.g., Add-In’s deployed via Click-Once).

5. Passing and Re-Adapting Add-In’s (ContractAdapter)

One of the many benefits of the Adapter model is the ability to Re-Adapt. Sharing Add-In’s without the demand to Discover and instantiate a new instance is a powerful capability.

We provide facilities to pass the Add-in around and let each consumer of it choose its own view and let the system find the appropriate adapter between the activated add-in and the requested view.

6. Add-in Activation Security enum

We have added a new enum value for activating the Add-in using the Hosts Security level (i.e., AddInSecurityLevel.Host).

7. View Hierarchies

We now support a hierarchy of view types and the ability to attribute them for discovery.

We will be posting more on these features in the coming months. Stay tuned.

Comments

  • Anonymous
    July 27, 2007
    VS 2008 and .Net 3.5 Beta 2 (code name "Orcas") is now available. Here is the link to download . I am
  • Anonymous
    July 30, 2007
    Jack,Does the UI Extensibility mechanism also extend to Cross-Process isolation, or is it restricted to Cross-AppDomain?Regards,Ian
  • Anonymous
    July 31, 2007
    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)
  • Anonymous
    July 31, 2007
    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
  • Anonymous
    August 01, 2007
    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
  • Anonymous
    August 01, 2007
    The comment has been removed
  • Anonymous
    August 01, 2007
    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
  • Anonymous
    August 01, 2007
    The comment has been removed
  • Anonymous
    August 16, 2007
    The comment has been removed
  • Anonymous
    August 16, 2007
    The comment has been removed
  • Anonymous
    August 17, 2007
    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
  • Anonymous
    October 11, 2007
    The comment has been removed
  • Anonymous
    January 09, 2008
    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?
  • Anonymous
    March 10, 2008
    The comment has been removed