ArtLeo's WebLog

get Control of your laser mouse

2009-11-08T07:39:29Z

Okay, so I bought the spiffy new Microsoft Arc Mouse from Microsoft at the Company Store. It’s sweet! I can fold it, put it in my pocket, show up at a meeting and still have a full-sized mouse. It’s awesome! I was the envy of my co-meeting-attendees for a day or so. However, these laser mice are more sensitive then the typical mouse. Even with the IntelliMouse support installed I still have to adjust the sensitivity down so that it stops going so fast across the screen. Now, the problem is that I...(read more)

Office 2007 / 2003 Compatibility

2008-02-12T20:57:00Z

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...(read more)

I've moved to the Trinity Team!

2008-01-08T20:01:00Z

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...(read more)

OpenXML - A graph, not a tree

2007-06-05T21:26:00Z

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...(read more)

Microsoft Document API for OpenXML

2007-06-05T01:42:00Z

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,...(read more)

Office System 2007 PIA Compatibility

2006-03-25T01:16:00Z

Office 2003 .NET-based solutions will run on Office 2007 without recompile...(read more)

Get signed up for the Office Developer Conference!

2006-02-15T05:12:00Z

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?

PIA registration issues

2005-11-18T01:04:00Z

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.

Office 2003 PIA Referencing Question

2005-09-20T00:42:00Z

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.

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

PDC '05 or bust

2005-09-10T05:03:00Z

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

PDC

Office 2003 PIA's are now available for redistribution!

2005-04-19T22:27:00Z

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:

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.
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!
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.

Office Developer Conference - Day 3

2005-02-04T20:47:00Z

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.)

Office Developer Conference 2005 - Day 1

2005-02-03T01:27:00Z

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.