MSDN Magazine Add-In Articles [Jack Gudenkauf]
The first of two articles we wrote for MSDN magazine was published online today (and available in newstands now): https://msdn.microsoft.com/msdnmag/issues/07/02/CLRInsideOut/default.aspx
This article introduces you to our APIs and walks through a sample application hosting add-ins. Next month we'll focus on V2 of the same application and go through the details of our architecture and how it solves the versioning problems.
Comments
Anonymous
January 15, 2007
The comment has been removedAnonymous
January 15, 2007
There's some good questions here, I'll try to get to all of them: "Compact Framework Support" Currently we are not shipping as part of the compact framework, but we're open to considering it in the future. If you can tell us a little more about the CF scenarios you've ran into that would have benifited by this system we'd love to here it. "Pluggin locations/deployment" We're very flexible as to where the pluggins are located. You can pass in network shares and relative paths to our API and as long as the current user has read access to those directories we'll be able to read all installed add-ins at those locations. We kept ourselves out of anything fancier than a disk based discovery/activation model because once people move beyond that their requirments diverge radically. Instead, we provide what's needed to build those systems on top of us. We'll have more on a future blog post (maybe with some interesting samples) but we're working with a few internal teams that will be building a database based deployment system as well as some that would like to discover and activate add-ins from the internet. "Naming" We more or less inherited this name from previous groups and in Visual Studio land everyone uses "Add-In" so we're used to talking about it in those terms. Besides, at least this way an internet search for add-in is more likely to be talking about us ;-) "Performance Costs" Again we'll have more information about performance in future blog posts but the good news here is that the overhead is quite low. Our perf tests show that if you are already using an appdomain boundary to isolate add-ins we add less than 1% to the cost of each cross domain method call. "Versioning" One of our primary goals in introducing this feature was to solve all these versioning problems that come back to bite you after you've released once and start working on version 2. We'll be talking about versioning and how our model addresses the various problems related to it a lot and our next msdn magazine article will include an overview of our architecture as well as demonstrate how you can keep old add-ins working, and run them side by side with new ones, even as the host and it's contract changes radically. The short answer is that the system manages versioning for you at runtime and that the host code itself will not have to worry about all the different add-in versions (and vice versa) but that you may have to build and deploy cross-version adapters to enable some of the more interesting versioning scenarios.Anonymous
January 16, 2007
Do you plan to get into a technical discussion for those of us who are familiar with things like Pratschner's book. I kind of want to know what's going on under the hood.It would be great to have something that "just works", but I want to know what's going on. We're working on the add-in issue right now. If we like what you're doing, is there any "go live" license so we can ship a product using the CTP libraries?Anonymous
January 17, 2007
Well, I doubt we'll have any hope of using stuff you're working on :( The CTP is the whole Orcas thing, VS and all. It would be nice if you had a separate download of just the Add-In classes and then roll it into the next version of VS, kind of like what the WinFx team did.I might get a go-ahead to use a go-live release of just the add-in technology (if it existed), but there's no way I'll get the go ahead to use a whole new version of the .Net framework, even if there is a go-live license.Anonymous
January 18, 2007
We'll be going into much more technical detail both as to the architecture our model prescribes as well as to details about what goes on underneath the hood. If you have specific topics you'd like to hear about please let us know.I'm not familiar with any plans around releasing go-live licenses of the Orcas .Net FX but I may have some good news for your about the Orcas .Net FX. It is going to be released in a very similar manner as the .Net FX 3.0 (WinFX) was. Orcas (3.5) .NetFX will not be a brand new release of the framework but rather a servicing of existing versions with a few additional assemblies.It will essentially be:.NetFX 2.0 + servicingWinFX 3.0 + servicingNew Assemblies (such as System.AddIn)This means that you won't have to worry about the deployment of the 3.5 FX impacting existing applications as it only includes a servicing of the bits existing apps are built against and won't bring down a brand new runtime or BCL.Anonymous
January 19, 2007
That's potentially good news about how it will be delivered, but without knowing any plans or timeframes for go-live licenses, we're probably still going to have to roll our own due to our product release deadlines :(Anonymous
January 23, 2007
Just to clarify my previous comment:The current plan is that the 3.5 NetFX will only be available as a single package that includes the three pieces I described above.As far as impact to existing applications is concerned it only includes a service pack to existing bits and so it will be safe to deploy.It will still be a full sized redist as it actually includes all of 2.0 and 3.0 (not just the SPs) + the new bits.Anonymous
January 24, 2007
Thanks for the clarification.If it's just a service pack to existing bits, does that mean we would expect the minor version numbers on the 2.0 framework assemblies to change, but they would still be "2.0.x.y"? I would assume that just means bug fixes, but nothing becoming obsolete, etc?Just realizing there will be "servicing" could make it a tougher sell internally, as our QA department would have to re-test things against the serviced 2.0 framework.Anonymous
January 31, 2007
Michael, We talk about Orcas (i.e., The next VS/CLR release after the current VS 2005/Whidbey) release as Red and Green bits. The Red bits are a servicing release (as you mentioned just non-breaking changes to Whidbey (i.e, VS 2005) CLR v2.0. The green bits are new features in Orcas (i.e., NetFX 3.5). The Green bits are were you will find the new AddIn libraries and things like LINQ.Checkout an old post of mine on the subject of red bits (http://blogs.msdn.com/jackg/archive/2006/06/09/624517.aspx).It is also confusing since we renamed WinFX and bundled the CLR 2.0 with WinFX (http://blogs.msdn.com/jackg/archive/2006/06/09/624438.aspx). This should all now be as clear as who's on first, since I don't know is on third ;-)Anonymous
February 05, 2007
Will there be a utility provided to auto-gen cross-version adapters (host adapter-contracts-proxy layer) from my existing application's OM?Anonymous
February 07, 2007
Great question Gary. We are contemplating a tool that would generate the pipeline from something like a contract, as well as a tool to generate a pipeline from an existing OM.JackGAnonymous
November 05, 2007
website:http://www.falkonz.comSearch engine optimization (SEO) is the process of improving the volume and quality of traffic to a web site from search engines via "natural" ("organic" or "algorithmic….