ArtLeo's WebLog

I got this  in my email today:

How do your comments on Office 2007bkwd compatability  (3/24/2006) jibe with Andrew Whitechapel's blog (8/23/2007) about retaining O2K3 when installing O2K7?  He warns, for example, that if you have Excel 2K3 and 2K7 on the same machine, and "...run Excel 2003...it will be using the 2007 PIA's...if there are breaking changes [in the PIA's] you're hosed."  (Andrew is part of MS's Office App team in the UK.)

 

Are you saying there are no "breaking changes", so Whitechapel's points are moot?  I am beyond confused.

Actually, Andrew now sits down the hall from me.  I was a reviewer on his book. 

His statement was about retaining Office 2003 on the box when you install Office 2007.  Mine was really about building a solution for Office 2003 and running it on Office 2007.

Regarding Andrew's comment, I know of only two breaking changes in Office that prevent compatibility at this level:

1. Excel's custom formatting API changed in their object model such that return types were changed, breaking compatibility and
2. Access' forms API isn't compatible via COM interop from version to version because they extend their interfaces in the middle of the API, breaking the vtable compatibility.  They need to to satisfy their VBA and forms customers.

The other issues you could run into have to do with COM registration.  When you lay down the Office 2007 bits, the 2007 PIAs get registered as the primary ones.  And even if you explicitly reference the 2003 ones, publisher policy will redirect binding to the 2007 ones, making sure that you will always get consistent types.  So, if you absolutely need the 2003 PIAs for the above reasons, this might be difficult.  Otherwise this should "just work".

Office tested the APIs for compatibility for this reason - knowing that we had to have a way to roll our Office 2003 customers forward. 

I hope this helps.

So, one year after working on Access 14 (which is going to be great), I've moved over to the Trinity team!  I'm literally right across the hall from Eric Carter.  After nine years here, I'm in an interrior office again, but at least Kevin Boske (who defected with me to the developer division) has promised to keep his blinds open so I can see just how bad it's raining. 

 So - to my friends over in Access and Office, it's been grand and will continue to be so!  Keep Access 14 great! 

It's been great so far - basically I just moved to a customer of the Office system, and I'm already helping out with things like Primary Interop Assembly compatibility and build / versioning issues.  It's been cool to come back into a programmability role since I have a certain affinity for developers, as I am one. 

So, for those getting started looking at the OpenXML SDK, the first thing you'll probably notice if you start recursively mining a Presentation file is that OpenXML is a graph.  Not a tree.  And yes, it can have cycles!

The Presentation format is the only one that currently takes advantage of this in the format, but it's certainly possible for Documents and Workbooks to take advantage as well. 

Seems simple enough - right?  The idea is that all your data is interlinked and essentially in 3rd normal form - one place for everything without needless redundancies. 

So, if you're going to go recursive on this puppy, remember to terminate your stack yourself!

Happy coding!

Sorry I've gone dark for so long.  Something about features you've been working on that makes it hard to talk about because you're so excited you can't hold it in - and you realize you have to say nothing. 

 We announced today the API for OpenXML!  For those of you who have kept asking and asking about how to manipulate the OpenXML file on the server (or anywhere) without having to launch the Office client - this is part of what you've been asking for! 

What's my involvement here?  Kevin Boske and I prototyped, spec'ed and pushed for the API to exist.  We continue to be involved as reviewers of the API and are really excited to see a team take on something we'd been dreaming about for a long time.  And it has been a long time coming, and we hope our fans of Office programmability are pleased with the progress.  Pushing for this work has been little hard to do as a developer on Access, which has no real investment in the document format at this point, but the win for the developer is too big a deal to miss.

This API will let you take the Office document and programmatically modify a document without the Microsoft Office System installed!  It's still pretty steep to do everything you'd want to do on the server, but this is a first step to making some dreams possible.

The problem this API specifically tries to solve is the problem of finding parts in the file format without reading hills of documents.  The XSD's posted on the ECMA site go a long way to help program the XML inside the parts, but it's a bit more of a challenge to just get access to the parts and just work with the document. 

How much of our code, our foundation work is just in the plumbing today?  If you remember the code snippets we've shipped, there were a lot of strings for relationship types, content types, and the like.  This drop begins to abstract away things like that - allows us (as developers) to focus more on the task of writing our solutions - not on the file format's intricacies. 

This API does not get away from parts and XML. 

I'll blog more on this later, but I just wanted to give a shout out to the guys who worked so hard on this!

So, after talking with a couple customers at the ODC, I thought it best to make it clear what direction we're going in with Office's Primary Interop Assemblies. 

To make it clear: Office System 2003 solutions will run on Office System 2007 without the need for a recompile, or any other change to your code. 

Vetrans of the PIAs will note this is different from the past.  Users of Office XP PIAs and Office 2003 PIAs had to deal with separate compilations and dependencies in on the PIAs to get their code to run right against the differing versions. 

This is a big step for us, and it took a lot of effort and object model policing by Office to make this happen.  Versioning assemblies that are dependent on type libraries is very, very tricky, and requies a whole new set of rules to get it right.  There are some tools one can use as well to get it right, but I'll reserve that discussion for later. 

How does it work? 

Assemblies in the GAC allow for what's called a "publisher policy assembly".  This assembly allows us to force assembly binding at runtime to access a different version of an assembly instead of the one requested.  When you're Office 2003-built assembly requests the Office 2003 PIA from the GAC, the publisher policy will get the Office 2007 PIA instead. 

The real trick in all this is that the Office 2007 assembly must be 100% compatible with the Office 2003 assembly.  This takes time and tools to make sure that what we ship for Office 2007 will allow the Office 2003-built IL to find every function call that it expects from Office 2003.  This requires the method signature (interfaceStrongname).(returnType)(memberName)(paramTypes) all be exactly identical.  If they do not match, the CLR wil yield a JIT exception. 

What it does not solve

Users of the new user interface in Office 12 know that there are a lot of wins and limitations when trying to access more obscure, deprecated features of Office 11 in Office 12.  This will not solve those issues.  You should read Jensen Harris' blog about programming against the new UI and make sure your old add-ins will continue to run properly. 

Also, this will not retroactively go back and allow you to run on Office XP. 

There are currently known issues in the Office 12 Beta1 Primary Interop Assemblies when running with solutions built on Office 2003.  If you encounter any of these and are a beta partner, please make sure to log what you found at BetaPlace. 

This posting is provided "AS IS" with no warranties, and confers no rights.

There should be plenty to talk about at the conference.  We may even have some folks from my team talking!

Hopefully I get to see some of the folks I've met over the last year... like Scott Bullen and folks.  It's great to meet these people whose lives you try dilligently to help out on a day to day basis. 

Kevin's got a great article up on his blog that might give you some key as to what he might talk about! 

http://blogs.msdn.com/kevinboske/archive/2006/02/13/531358.aspx

Hopefully we'll be able to talk about Primary Interop Assemblies and things developers can do to keep compatibility between versions.  PIAs are not easy to enforce for .NET compatibility, and there are lots of things we've leared over the last couple years! 

Has anyone out there in the blogosphere tried out using the Office 12 PIAs yet in the Beta?

I read you webblog about the Office 2003 PIA installed in the GAC. I have found several issues that make this solution extremely problemmatic for developers.

First, I currently compile my Visio 2002 addin on a box that does not have visio on it. I can do this beacuse I reference the Office XP PIA's directly. I have ported my Addin to Visio 2003 and found that I can't install the Visio 2003 PIA without installed visio 2003 on my build box. So no I am forced to install another copy of visio 2003 on my build box so the PIA will show up in GAC.

Secondly, I have to support both versions of Visio for my addin. I have both versions installed on my development box. When switching between the two versions, a configuration process is run. This process only runs when running the opposite verison of Visio from the last version that was run. I have noticed that when I run Visio 2002, and the config process is run, it messes up the Visio 2003 PIA in the GAC. When I go to compile my addin, I have to run RegAsm on the Visio 2003 PIA to get the reference to validate.

Any comments on my issues would be greatly appreciated. Please feel free to repost my comments if you like.

Thanks

Mike

Using the PIA redist without Microsoft Office System 2003 is just not a good idea, which is why we went to some lengths to prevent it. The redist is meant to be a runtime solution for redistributing the PIA's to your clients using the Microsoft Office System 2003. 

For example, if you have a PIA registered for a type libary but you don't have the type library on the system, OLEAUT can get into a bad state.  In the PIA case, let's say you have Microsoft Excel 2002 (version 10) installed and registered on your system.  Your type library is version 1.4.  Let's say the PIA for Office 2003 gets registered and you didn't update Office.  This means you have a PIA for version 1.5, but a type library for 1.4.  While the PIA can be happy (sort-of) OLEAUT isn't.  If you reference the type library from anywhere other than Excel's VBA project (which has some resiliency to this versioning issue), referencing the type library will OLEAUT.  OLEAUT will walk the registry and see versions 1.4 and 1.5.  It doesn't know that 1.5 doesn't really have a type library.  So it tries to get the type library for 1.5.  This then results in a failure because the 1.5 type library isn't present or registered.  (The 1.5 type library BTW lives as a Win32 resource in Excel.exe.)  OLEAUT then does NOT unwind to use an older version (like 1.4, which IS present.)  It just fails. 

To sum up that long explanation: registering a newer PIA than you have a type library for will work, but OLE will fail, and LOTS of things use type libraries.  (I'm not sure here, but embedded objects of Excel may stop working there, or in your case, Microsoft Visio.) 

I am personally unfamiliar with Visio's "side-by-side" running nature, but is sounds like they re-register their type library using standard system calls to make sure that the right version is registered (likely for the same reasons as stated above.)  Perpaps you can respond with who's doing configuration?  Is there some custom code running? 

Anyway, what's probably happening is that the type library is getting re-registered.  When that happens, the call that registers the type library first wipes out all child keys and values from the root of [HKCR]\typelib\[TYPELIB_GUID]\[version]\.  This means the PIA registration goes away!  We've been working with other teams to try to remedy these problems at least at installation time, but something like changing regtlib.exe would be difficult to do, since it's worked this way for over a decade. 

While I know this doesn't really solve the problems, I hope it provides you some insight as to why they exist.  If there's some custom config code you have for switching the Visio versions... we can work with that.  Let me know if it's not custom code that's switching Visio versions. 

Thanks!

- Art

 This posting is provided "AS IS" with no warranties, and confers no rights.

Jim wrote:

Its great to see that MS has provided a redist for the 2003 PIAs but is there any plan to turn the PIAs into files.

My issue I can't use the /reference flag of csc when trying to develop assemblies that use the 2003 PIAs?

Jim

You should be able to refer to the PIA's directly in the GAC in c:\windows\Assembly\GAC\[whateverpiayouwant]\[version_pubkey]\[pia.dll].  I understand it's not optimal.  VSTO and Visual Studio do some work to make this easier.  If you're using NMAKE, you should be able to refer to your Windows install directory without a problem. 

I also encourage you to check out the Office 12 Beta 1 when it becomes available. 

Please feel free to comment on this post so that I might be able to help further. 

See you all at PDC!  It's going to be great to finally get to talk with you about Office 12 and building solutions on top of the infrustrcure in the new product.

I should be in the Office and Shaprepoint track lounges most of the time.  I'll be the one in the blue shirt.  ;-) 

For those that don't know me personally, I work on Office Programmability.  We're not VSTO, though we work together quite often. 

See you there!

- Art

http://www.microsoft.com/downloads/details.aspx?FamilyId=3C9A983A-AC14-4125-8BA0-D36D67E0F4AD&displaylang=en

I didn't contribute much, but after lots of hard work, we've finally got this ready.  I know lots of folks have been wanting an easy way to deploy solutions using .NET in Office 2003.  Well, this is it!  This should address those folks that want to package up individual PIA's and put them on the machine themselves... this is really the way you want to go.  Why?

You'll want to read up on the Windows Installer, but the bottom line is that: 

1. Component stomping.  If you have two products that package the same file in the same directory but use different components in their installer, then the ref counting on the component will not work properly.  The first one to be uninstalled will uninstall the shared file, breaking the other component using it. 
2. The GAC is where we should be pulling interop assemblies. The CLR has limitations as to loading interop assemblies.  Once you've loaded a handler for a given CLSID, you're stuck with if for the entire appdomain.  So, if you have two components in the same app domain that demand different versions, or expect different files  / classes / types to talk to the same COM object, you'll be out of luck!
3. There's a couple more things... I'll write about them later.

Now, a couple things you should know before you start trying to put this everywhere:

• The installer requires Office 2003 installed on the system.  It isn't designed to offer compatibility with Office 10 or 9.  It will not deploy on 10 or 9.  We can talk about real-world compatibility another time.  This isn't that solution. 
• You don't want to go pulling components out and try to treat this as an MSM.  The reason is servicing.  When (if) Microsoft needs to do a service update for the components (PIA's), it can only be done on MSI's.  Leaving this as an MSI will make sure that we can service the component.  This could be for security.  The utmost scrutiny is taken to make sure that we do not break compatibility.

One last thing:

• Make sure you test your solution on the CLR 2.0 betas!

That said, there was a lot of hard work that went into developing and testing this.  You folks know who you are, Bryan, Kintan, and Andrea.  Having handled the PIAs and the installer in Office 2003, I know what a challenge this can be. 

You guys rock. 

- Art

 This posting is provided "AS IS" with no warranties, and confers no rights.

In case you were wondering, VSTO rocks.

I am curious about folks writing managed code for Office without the comfort of VSTO.  (Please add feedback if you do.)  VSTO adds a lot that makes using the Office PIA (Primary Interop Assemblies) much easier to use. 

(More to come.) 

Hi! 

For those that don't know me, which is probably most of you, I am an Office developer working on programmability features.  I've worked on the primary interop assemblies, VBA, and some of the object model.  Previously, I worked on globalization in Office. 

Anyway, I am attending the Office Developer Conference, and what a turn out it is!  It's amazing the types of solutions people are building on the Office toolset. 

Look for posts on tips and issues with regard to using the Office Primary Interop Assemblies.  I am very excited about the opportunities and challenges in this space.  Other bloggers that post related articles include Siew Moi Khor and Peter Torr. 

Anyway, I hope everyone's enjoying themselves at the conference.  I am hearing about a lot of neat solutions that have been put together using Office and managed code!  It's great to see customer excitement about developing with Office!

Anyway, HI! 

Art Leonard, Office Programmability Development

This posting is provided "AS IS" with no warranties, and confers no rights.