You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Writing managed code against the 2007 Microsoft Office System products requires the use of an interop assembly. Just as we did with Microsoft Office System 2003, we are providing primary interop assemblies with the new 2007 Office. We’ve also made some changes to make the PIA’s a better experience with 2007. Among the areas we’ve addressed are:
Installation
In Office 2003, the PIA’s were set as an Install on Demand feature within Office Setup. This caused some headaches for the Office developer because you could never know for sure if the PIA’s were installed on the machine where you were installing your managed add-in. With 2007, we will be changing the default feature state for the PIA’s to install locally. While this will narrow the cases where the PIA’s are not installed on the machine, it doesn’t take care of 100% of the scenarios such as the .NET Framework being present on the machine during the Office installation. To catch these other scenarios, we will also release a PIA Redistributable package.
Redistribution
During the spring of 2005, we released a PIA redistributable for the 2003 Office PIA’s which now gives you the license to redistribute the PIA’s with your solution. With 2007 Office System, we are releasing another redistributable containing the 2007 PIA’s and associated supporting files. Now, by taking the redistributable package and shipping it with your project, you can ensure that the PIA’s are installed properly when you install your solution.
Backward Compatibility
Backward Compatibility is an area we where have focused much attention. We understand that as a platform, we must take steps to ensure that the managed solutions compiled against a 2003 PIA will continue to run properly against the 2007 version. To do this, we’ve taken some great strides during development of the individual object model to ensure that the changes to the OM do not break runtime compatibility.
In conjunction with the OM compatibility work we have done, we are also shipping publisher policy files for the Office PIA’s. These will automatically redirect code that is compiled against the 2003 PIA to the new 2007 PIA so that existing code compiled against a 2003 PIA will automatically be redirected to the corresponding 2007 PIA. As with any publisher policy, in cases where you may not want to redirect code to call the new PIA, you can override the policy by using the following tag in an application configuration file shipped with your managed assembly.
<publisherPolicy apply="no"/>
For more info on publisher policy, see this link.
Comments: (4) Collapse
Backwards compatibility is great but I feel that, from what you say, there is nothing changed in regards to the handling of optional method arguments in the object model using .NET : we already know that, unless you are using VB.NET, code patterns are ugly and needlessly complicated.
Yes, you are correct that optional methods are unchanged. We know that this is a pain point and are reviewing the issue.
With 2003 PIAs, it seemed like we had some trouble killing instances of Excel, and had to call the GC several times to get rid of them. Is this fixed in 2007 PIA?
Hey Kory,
The issue of releasing Excel when controlled via .NET automation is not well understood and often incorrectly documented. The problem is not with the PIA's, but is instead dictated by the issues regarding .NET vs. COM object disposal. If you do it right, however, Excel should release every time.
As a quick example, the following code "looks ok", but is actually flawed and Excel will hang:
-----------------------------------
rng = nothing
ws = nothing
wb.close(saveChanges:=False)
wb = nothing
xlApp.Quit()
xlApp = nothing
GC.Collect()
GC.WaitForPendingFinalizers()
There are two problems with the above:
(1) Although the code appears to dispose of the 'rng' object first, the 'ws' object next, etc., the code above does not actually *enforce* this as the .NET Garbage Collection procedure can dispose of its objects in any order. (GC is non-deterministic in order, not just non-deterministic in timing.)
(2) Commands such as 'ws = wb.Workssheets.Item(1)' -- or lines like it -- are very common and will create an RCW object wrapping a 'Worksheets' object. You won't have a variable holding a reference to it, so you don't generally think about it, but this RCW object will not be disposed until the next Garbage Collection. However, the code above calls GC.Collect() *last*, and so the RCW is still holding a reference to this 'Worksheets' object when xlApp.Quit() is called. Excel hangs as a result.
The correct way to clean up and exit out of Excel is as follows:
Marshal.FinalReleaseComObject(rng): rng = Nothing
Marshal.FinalReleaseComObject(ws): ws = Nothing
wb.Close(SaveChanges:=False)
Marshal.FinalReleaseComObject(wb): wb = Nothing
Marshal.FinalReleaseComObject(xlApp): xlApp = Nothing
The above will release every time. :-)
Note that Marshal.FinalReleaseComObject() is not available in .NET 1.0/1.1 and so if you are using VB or C# 2002/2003 you would have to use Marshal.ReleaseComObject() instead. But keep in mind that Marshal.ReleaseComObject() should be executed within a While loop, until Marshal.ReleaseComObject() returns 0.
If you want more info, I had a recent post on this topic: www.xtremevbtalk.com/showthread.php
-- Mike
Comments: (loading) Collapse