In case you are unaware, we're close to shipping Visual Studio 2008 (aka "Orcas").  I hope that's not really a suprise.

A bit of trivia on the code name "Orcas".  When when VS 2003 came out the code name was "Everett".  Everett is the name of a town just north and west of Redmond, Microsoft's headquarters.  If you drew a roughly straight line on a map from Redmond through Everett extending further North and West you'd be in the proximity of things like Camano Island, Whidbey Island, and Vancouver Island in British Columbia, Canada.  Whidbey was the codename of the VS 2005 release.  Orcas Island is another one of the islands in this area of the map and that's why VS 2008 is codenamed "Orcas".

There's a follow-on product to VS 2008 to update a bunch of tools in the Team System family of Visual Studio tools including some new tools.  This release is code named "Rosario".  Rosario Resort happens be a very nice area on Orcas Island.  If you ever travel to the Pacific Northwest and want to visit a first rate resort with excellent accomodation, entertainment and food, Rosario Resort is a great place to visit.  Rosario will also be a great release of tools from Microsoft.

So, with that bit of trivia behind us...

I'll be in Redmond the week of 10/15 for the VSIP Summit taking place that week.  I'll be presenting info on what I've been working on here is the Hawaii Development Center.  If you are at the summit, please say hello.

We plan to put what I've been working on into the CTP of Rosario that will be coming out in the next month or so.  If you happen to be on the distribution of that preview, I'd love your feedback on the release.  More details to come in the next few weeks...

I've been working in the VS Extensibility area for quite a few years now.  But the time is right for me to venture forth into a new area of responsibility for Microsoft.

I'll be helping to form a new team based in Honolulu, Hawai'i, USA.  Microsoft is opening the Hawaii Development Center there and I'm one of the most fortunate individuals on the planet to share in the experience.  In the future, I'll be blogging about the HDC and this new project so stay tuned for more info on both of these areas.  I'll be redesigning my blog appearance to reflect a more tropical attitude, but the address will remain the same.

So, I won't be in Redmond any longer (as of Friday 5/18).  We recently held a VSIP Developer Conference and I was a little nostalgic helping to host my last Dev Lab (as they used to be called).  I've also gotten to know some of you via trade shows like Tech*Ed and the PDC; I don't know if I'll be able to join you in those shows in the future, but I hope so depending on what content we have to offer from this new project.

It's truly been a pleasure to work with the VSIP partner community and the VS SDK team over these last few years.  I'm extremely pleased with the VS SDK we provide and most of that pleasure comes from the great feedback we've received from the VSIP partner community.  There's certainly more that can be done in the product and making extensibility easier is one of the main goals of the team.  It's great to see how many people are getting involved with VS extensibility and how the general VSIP community is growing; helping one another along the way.  It's been great working on the VS core product and helping so many VS SDK users to extend VS in so many interesting ways.

The VS SDK is in good hands.  My change of focus provides an opportunity for the rest of the team to shine.  They've always been providing the awesome SDK you consume anyway and I've been lucky to have worked with them.  The plans for the Orcas VS SDK are solid and the energy the team is putting into the product and the ecosystem is awesome.  The future is very bright for the VSIP community.

I wish you success in your VS extensibility endeavors.

Mahalo,

Allen

Last week we released the VS SDK for VS "Orcas" Beta1.  You can use this lastest version of the SDK to build VS Integration packages and DSL Tools-based packages that target VS "Orcas" Beta1.

To get this version of the VS SDK requires access to the http://www.vsipmembers.com site.

James Lau blogged some of the details of this release.

Please check it out and provide feedback.  The best way to provide feedback is via the Visual Studio section in the Microsoft Feedback Center on MSDN.  You can use this link to access the specific area for Visual Studio feedback. 

If you'd like to discuss the VS SDK or have questions about VS Extensibility, the best place to go for online help is the Extensibility forum on MSDN.

The Running Document Table is used in VS to control the state of opened documents.  This is only accessible via interfaces exposed in the VSSDK and the VS Automation Model.  End-users only see the effects of the RDT in places like the dialog that pops up asking the user if they'd like to save changes before closing the IDE. 

The underlying implementation in previous version of VS had some problems with reentrancy protection being inconsistent.  Additionally various entry points weren't very robust with error handling (some would crash, other return error results, etc).

One of the excellent developers in the Developer Tools Platform team responsible for the base VS platform took it upon himself to make a clean sweep through this area of the codebase and came up with a number of improvements.  He sent me a document with the changes that he thought the 3rd party community might be impacted by.  I wanted to share that information with you.

One important point to make here is that the interface methods of IVsRunningDocumentTable have not changed.  Binary compatibility is preserved so you don't have to worry about your code not compiling in Orcas.  If you don't use that interfaces in any way, then you don't have to worry about this at all.  But if you do use the RDT interfaces, then you need to check your code on how you interacted with the RDT to see if any of these changes affect your runtime behavior.

Here's a synopsis of an email thread that discusses the changes introduced in VS Orcas.  These changes were available in the Sept 2006 CTP of VS (and all susquent versions).

Thread affinity for the RDT has been tightened.  With the exception of the following methods, all RDT interface methods must be called on the main thread, else RPC_E_WRONG_THREAD will be returned:

 

• GetDocumentInfo
• FindAndLockDocument (with RDT_NoLock)
• FindAndLockDocumentEx (with RDT_NoLock, as long as the document exists and has a hierarchy/itemid)
• FindOrRegisterAndLockDocument (with RDT_NoLock, as long as the document exists and has a hierarchy/itemid)
• GetRunningDocumentsEnum
• All methods on IEnumRunningDocuments.

This restriction was only inconsistently applied in previous versions.

The externally-visible change in behavior for the RDT will include, but is not limited to, the following:

· The RDT lock will be faithfully acquired on any call into the RDT.  This is handled sloppily in the RDT in previous versions, and more rigorous treatment of the RDT lock has the potential for introducing deadlock where none existed in previous versions.

· The RDT lock will not be held when calling out of the RDT.  This also has the potential of causing deadlock where none existed in previous versions.

· Interfaces held by the RDT will be released (i.e. not leaked) for documents left in the RDT when it is destroyed.  This only happens on shutdown, so this should be a no-op for packages.

· IVsRunningDocumentTable::RegisterAndLockDocument will require an IVsHierarchy when a document is registered with an edit lock.  The documentation specifies this, but the code did not enforce it.  There are several other code paths where this invariant can be violated as well.  Increasing enforcement could be an issue for packages.

· IVsRunningDocumentTable::UnlockDocument will not allow unlocking of a lock if a lock of the specified type is not held.  In previous versions you can UnlockDocument(RDT_EditLock) even though you never acquired an edit lock.  Fixing this could be an issue for packages as well.

What is the new behavior if the call is made and the type of lock specified is not held? The following code illustrates the differences:

pRDT->RegisterAndLockDocument (RDT_EditLock, ..., &cookie);

pRDT->UnlockDocument (RDT_ReadLock, cookie);

pRDT->GetDocumentInfo (cookie, ..., &cReadLocks, &cEditLocks, ...);
pRDT->UnlockDocument (RDT_EditLock, cookie);

In previous versions, the Unlock(RDT_ReadLock) would return S_OK, the GetDocumentInfo would return cReadLocks=0xFFFFFFFF and cEditLocks=1.  After the Unlock(RDT_EditLock), the document is still in the RDT (visible to enumerators, etc.).

In VS Orcas, the behavior will change so Unlock(RDT_ReadLock) will return failure, meaning GetDocumentInfo will correctly return cReadLocks=0 and cEditLocks=1.  After the Unlock(RDT_EditLock), the document is no longer in the RDT, event sinks have gotten OnAfterLastUnlock, etc.

·       IVsRunningDocumentTable::UnregisterDocumentLockHolder will AV with an invalid cookie.  The fix would turn the AV into an E_INVALIDARG.  This should present no issues for packages.

·       Documents enumerated by IEnumRunningDocuments will be enumerated in a different order.  There is no order expressed or implied by the interface definition, and the current order is based on the hash of the document name so it’s unlikely that the current behavior is stable enough for a package to have dependencies on it, but it’s theoretically possible.

I was recently alerted to an email sent to Soma (Vice President leading the Microsoft Developer Division) about a problem with the VS SDK's MPPG/MPLEX tools.

Here's the question:

After installing VS SDK (feb 2007) and trying to play with the managed parser generator (MPPG/MPLEX), it seems that the MPPGRuntime.dll, discussed in the documentation and needed to use the output from the command line tools, is missing.

I've searched the whole installation of the VS SDK and looked in the GAC without success.

Can you point me to the appropriate contact to help me resolve this issue?

The dll mentioned (MPPGRuntime.dll) doesn't actually ship. It's an error in the documentation that it is mentioned.  I'm working on getting the documentation issue addressed in a future release.

Originally the code in the runtime dll was used both by the tools (MPLEX, specifically) and the generated code.  If this had continued to be the case, then a generated parser would not work at all without the dll.  The dll would be required to be redistributed with the parser.  This complicates things because if Microsoft supplies a dll that a 3rd party ships, then Microsoft is responsible to service the dll.  So, now we're talking about an MSI that would be chained together with the parser installer.

To simplify deployment and servicing complexity, I removed the dll and instead placed the code into MPLEX directly.  Additionally, because the generated code needed the functionality, we shipped the source code in the Managed Babel folder of the VS SDK.  (See the sample in the Example.ManagedMyC folder for details.)

So, there's no need for a runtime dll and you can use the tools to generate a language service with much simpler deployment.

Talk to you later on,

Allen

On behalf of the VS Tools Ecosystem team, I am pleased to announce that after months of hard work, VS SDK 4.0 has been released! This is the last SDK release planned for Visual Studio 2005. The team has done a ton of work to make this release friendly to developers who are new to Visual Studio extensibility. It is available for immediate download on the Microsoft Download Center.

Some of the new features included in this release:

• VS SDK Browser – the new entry-point to the entire SDK; includes new QuickStart Tutorials and a completely revamped sample browsing experience, community resources and tools info
• Package Load Analyzer – allows you to easily diagnose package load failures
• Toolbox Installer redistributable package – allows component vendors to simplify deployment, along with a sample demonstrating how to do it all. 
• Sandcastle – new set of tools for generating managed class library documentation

There's an article in eWeek for this release. (That's a first for the SDK as far as I know.)

We're putting the final touches on the v4 VS SDK for VS 2005. 

The team and I have been hard at work ensuring it is at a high level of quality. The content is out of this world.  There's a few new samples to start with, a new SDK browser connecting you to community resources as well as sample content, tutorials, documentation and tools.  There's a Package Load Analyzer tool than can help with Package Load Failure and other package load issues you might encounter in testing and production environments.  There's also a Toolbox Controls Installer package, sample code and documentation (including a tutorial) for control vendors to see how we recommend integrating controls into the VS toolsbox.  Note: The Toolbox Controls Installer is expected to be in the next release of VS (aka Orcas) so any code that works with v4 of the SDK and V2005 should work without little or no change in Orcas.

Keep your eyes on this blog in the coming days for the release announcement...

My first trip to Europe is turning out to be great!  The city of Barcelona is great.  Many attractions to see, lots of nice things to do.

Sunday and Monday this week the VSIP team conducted a Developer Lab with lots of great presentations and 1:1 meetings discussing extensibilty.  We ended that event with a dinner for Lab attendees and partners at TechEd at a Flemenco show.

Now we are in the middle of TechEd: Developers (next week is the IT conference).  Lots of great presentations at this show and about 4000 people in attendance (some 700 staff).

My own theater-style presentation was well attended compared to TechEd US this summer. I wrote code to build a package on stage.  Gareth Jones joined us today for a packed theater presentation on the DSLTools that come with the VS SDK. Additionally partners companies that presented have met with great success in attendance. Most attendees treated the theater like a real session venue staying for the entire presentation.

A lot of good traffic through the VS SDK booth on the first day. Typically we play a triage role finding the right people for the attendees question and did so this event, but there were quite a bit of questions directly related to the VS SDK and extending Visual Studio. The session presented on Tuesday afternoon was a hit with a medium sized full room (not packed tight and not sparse). Some good questions after the session and good opportunity to drive traffic to our booth.

I took some time to visit a session on SharePoint customization on Wednesday.  SharePoint itself is totally awesome and great a collaboration platform.  I was unimpressed, however, with the SDK to provide code that can customize a site.  There were several points where I thought that a schema file for some XML configuration files would be very effective at preventing authoring errors.  Additionally there are several opportunities for custom project items or even custom projects that would make the development and deployment of SharePoint customizations much easier to accomplish.  Definitely a partner opportunity.

More on TechEd and my first trip to Europe when I find time to post...

Allen

If you author a package or add-in for VS, we encourage you to download the VS 2005 SP1 Beta in order to determine if there are any modfications to your package or add-in that need to be done in order to be compatible.  It is very likely that there is nothing you need to do to support SP1, but if I were you I wouldn't leave it to a user to discover a lurking problem.

Here's a link to the Beta announcement.

Below I've pasted the VS SDK Product Backlog for version 4 of the VS SDK.  We're planning to ship this version of the VS SDK in mid-December.  This will be the last revision of the VS SDK that supports VS 2005.  We'd love to get some feedback on these features and work items. 

The major areas of focus for V4 are to

1. enable community collaboration,
2. ease component vendor pain, 
3. improve the user experience getting started with the VS SDK and
4. get a start on some VS Orcas platform and SDK work. 

Those themes drove the decisions we've made so far, but we need feedback from VS SDK users to ensure we are driving toward a successful release for V4, so please don't be shy about letting us know what you think of our plan.  There is, of course, much more we'd like to do, but have to combine a lot of competing priorities and limited resources in order to come up with the best update we can for this time-frame.  Your feedback helps us to understand how best to compromise on priorities and align resources.

You can visit the VS Extensibility portal for the latest information and resources.  Follow the links to get the SDK (note there's now an easier way to download at the bottom of this mail).

Some really cool things in this release:

• Power toys (Check out the Source Outliner tool)
• New Samples (Iron Python now does Web Sites and Web Application Projects)
• Updated less-restrictive license
• Freely available on Microsoft download site.

Check out the VS SDK documentation on the web! 

No longer are the VS SDK API's only doc'd with the VS SDK itself.  Now you can get up to date documentation anytime without having to install anything locally.  You've been able to do this for sometime with the VS documentation (including the .Net Framework) and now you can do the same thing for the VS SDK API's.  Cool.

More info about this on Paul Cornell's blog...

I've finally gotten around to trying out the VS SDK on Vista with UAC turned on.  Here's what I had to do to get the VS SDK to install, and a package to compile and run:

1) Installing VS - fairly straightforward, no surprises

2) Installing VS SDK - the self-extracing exe fails to launch setup.exe and the system pops up an ugly message box indicating that setup.exe can't be started.  Solution: run the self-extracing exe with the '-x' switch and specify a directory to extract to.  Run setup.exe from the specified directory.  You'll need to enter admin credentials in order to complete the setup, but it should be straightforward.

3) VS SDK installs all of its content directly to the Program Files folder and folder is restricted in Vista.  Opening a sample and attempting to build it results in errors about the output directories.

Solution:

a) Copy all of the VisualStudioIntegration\Samples folder to your personal documents folder (on my system it's c:\users\allend\documents).  I placed my copy of the sample code into the Visual Studio 2005 \ Projects \ VSSDKSamples directory. 

Moving the sample files around breaks them because there are relative references to other files (relative means the directories are specified with '..' to move up the directory from the current path).  These references are now broken.  As a matter of fact when you open a sample solution the project will fail to load (you'll get an error message). 

Solution:

b) Right-click on the project file in the Solution Explorer of VS.  Replace all strings like '..\..\..\..\Common' with 'c:\Program Files\Visual Studio 2005 SDK\2006.04\VisualStudioIntegration\Common'.  This will make the references to the files absolute instead of relative.

c) You can do the same with the Overview.xml file that comes with the sample.

d) Try building the sample now.  It should build.  If not, continue to look for relative file paths and fix them up.

Registration is still a problem.  The sample build causes regpkg to run, but it places it's values in a virtual registry location that devenv.exe doesn't actually look at when looking for registered packages.

Solution:

e) Registration - for now you'll have to do it by hand - you can use the /regfile option of regpkg to create the file, then you should be good to go.  Native package will have to do something similar, but there's no tool to create a .reg file out of the rgs data in the native resources.  Once you have a .reg file, remember to run the command prompt (or regedit.exe) as an administrator.  Running as a normal user and importing .reg files causes errors to be reported and registry entires aren't actually put in place.  I did this by spawning a command prompt as Adminstrator in the Vista start menu.

Running:

e) Close the solution and reopen - in the previous open of the solution the VS SDK solution extender didn't work to place the debug information into the sample (for automatically configuring what should happen on F5 - Debug Launch).  Closing and reopening the solution makes the debug info work properly.

f) Get "DevEnv /setup /root Exp" to run after you registered your package by hand.  This will at least get the menus to be recognized for your package.  The easiest way to do this is to touch your .ctc file, getting it to rebuild will trigger the setup step to occur.

I know the instructions above are really involved and there's a bunch of stuff that should be done automatically, but unfortunately the VS SDK for Whidbey wasn't built for this.  Until we make some changes to the tools and samples this is the best I can offer.

Good luck,

Allen

My apologies at not blogging more often, but TechEd became even more of a blur in the last days and I simply had to let it drop.  Perhaps if the network were better behaved...

Day 3

Wednesday during the day was like any other.  Lots of potential partners and lots of general VS programming questions.  I got to visit the show room floor a little bit and see some partners products.  I'm particularly happy to note that Statesoft got a little issue fixed and are ready to ship their product.

Wednesday night Joe, Varun and I attended the VS Magazine's Readers' Choice Awards ceremony.  We played a little pool, had the buffet and then rooted for partners up for awards. 

Day 4

Thursday was definitely seeing less traffic in the booth, but still steady.  I was happy to see a few more partner demos in the pavillion.

Thursday night was the all-attendee party at Fenway Park with a concert by Train and a local band.  There were labor demonstrations against one of the bus companies used by MS during TechEd so we arranged for a police escort and they closed off the streets for the busses that moved everyone from the convention center to the ballpark.  This was the highlight of the conference for most customers.  Those who sat behind me were extremely vocal about how cool this was.

Day 5

Friday was a lighter heavier in traffic as people were trying to get their last questions and demo's in.  Our Chalk Talk (last hour of the entire conference) was attended by only 3 people, but we had a lively discussion and those who came were appreciative of the intimate attention they received.

This was the impression that I received from talking to partners: the VSIP partner program is on track and the improvements over the last year or so are very much appreciated by the partners.

I took the subway back to the hotel, but stopped off for a bit of pizze before getting some sleep before the early plane home on Saturday.  After the pizza I decided I needed to get a few souveniers so I wandered around downtown for a long time.  Ended up with a few gifts for my wife and children so I decided to go back to the hotel and get some sleep.  Upon entering the room, I looked around for my laptop.  Where was it?  Oh no, did I leave it on the subway?  Or one of the shops I visited?

I rushed around the block to the pizzaria (very good pizza by the way) and it was closed.  Looking in the window I could see my backpack on the counter.  Long panic-filled story short: Concierge at the hotal picked up the back on Saturday and Varun carried on the plan back to Redmond.  Disaster averted.

Well, I'm exhausted from being on my feet too long and working, partying, hosting so much.  Glad to be back in Redmond now.

Tuesday was an extremely full day.  Partner meetings continually, booth duty for a large part of the day.  The traffic in the booth has been steady and we are getting a variety of interest in the VS SDK, the VSIP program and other miscellaneous questions also.  It felt great to help solve a few of the technical issues that partners were facing and to provide suggestions on improvements in the future.

In the evening we hosted a party for VSIP Partners at the Improv Asylum.  Absolutely hilarious. They got Joe up on stage for a little while for an interview and then based on his typical day the cast did a "Day in the life of Joe".  Terry also got up for a little Q&A with a couple of consultants.  Overall the funniest things I've seen in a long time.  Total geek humor too.  It was great.

After that we crashed the MSDN party at the Boston Billiard Works (near Fenway Park).  Played some pool, lost some games to a couple of folks on the 6th floor of Bldg 41.  I tried defending the 5th floor, but just wasn't up to the task.

Exhausted.