none
Suddenly seeing failure to load Microsoft.Office.Interop.MSProject PIA RRS feed

  • Question

  • For years, I've been distributing a .NET application that uses the Microsoft Project Primary Interop Assembly listed in the title.  Starting last Thursday, Feb 28, I've had three reports from the field that customers are unable to load my application because this PIA no longer loads.     Here is the error message:

    System.IO.FileLoadException:

    Could not load file or assembly 'Microsoft.Office.Interop.MSProject, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies.

    Access is denied.

    File name: 'Microsoft.Office.Interop.MSProject, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' 

    It appears that all three of these customers have recently upgraded their installation of Microsoft Office 365.  I suspect that recent Microsoft update to Office 365 has somehow broken the loading of this standard Microsoft assembly.  

    This is bad.  Any ideas out there?


    ...Jim Black



    • Edited by Jim Black CG Monday, July 8, 2019 4:37 PM clarify title
    Saturday, March 2, 2019 3:30 PM

All replies

  • Hi Jim,

    Have you reproduced this with the last Project Online Desktop version? If so, what build? You will need to open a support call with Microsoft via your Office 365 tenant.

    Paul


    Paul Mather | Twitter | http://pwmather.wordpress.com | CPS | MVP | Downloads

    Sunday, March 3, 2019 9:49 AM
    Moderator
  • Hi Paul,

    Thanks for the quick response and suggestions.  They confirm my current course of action.  We're working on reproducing it, but need to figure out how to download and install a specific build of Project/Office 365 desktop.  There is some evidence that it may not be the latest Project Online Desktop version and could be the next-to-last.  Do you know how frequently Microsoft pushes out new builds and how to get a list of those builds and their availability dates?  One affected customer has provided me with information from the File> Account >About on a computer that is definitely failing.  Here's what he provided for both MS Project and MS Office 365 (Excel).  Do you know how to interpret the Product ID and Session ID strings to trace them back to O365 downloads that I could grab and test?

    


    ...Jim Black

    Sunday, March 3, 2019 2:48 PM
  • Hi again, Paul!

    Never mind my question about figuring out the history of Office 365 releases.  I found that information, all 300 pages of it, online at Microsoft Office 365.   I have confirmed that the specific version of Project 365 is not the culprit because I and the users have the same version of Project 365 desktop installed.  So it must either be a recent change to Office 365 or to Windows 10.  I'm gathering in formation on the Windows Specification of one of the recently-affected computers and will try to match that along with Office and Project.


    ...Jim Black

    Sunday, March 3, 2019 7:53 PM
  • I've recently encountered the same problem - on Windows 10 with an Office 2013 installation. Strangly enough when I run the .NET executable 'as administrator' the problem disappears, so it definitely seems to be a permission problem.

    I've noticed the problem disappears when Repairing the Office 2013 installation, but then a few days later it resurfaces again. Quite strange. This has worked for years without any problems and is causing a lot of discomfort for customers.

    Anyone any suggestions?

    Wednesday, May 8, 2019 12:32 AM
  • One change seems to make the problem go away, at least in several cases we've encountered among our customers.   If you embed the Microsoft Interop assemblies into your assemblies, the load problem seems to go away.   Embedding Interop interfaces into .Net assemblies has been supported by Microsoft since .Net 4.0.

    ...Jim


    ...Jim Black

    Wednesday, May 8, 2019 1:36 AM
  • Yes, but that is a really clumsy way of solving it - we prefer lean assemblies and executables, so we only have to update the changes instead of having to package embedded assemblies.

    For us it only occurs on one specific W10 system, we just need to get to the bottom of the permission issue here to solve it :-)

    Tuesday, May 14, 2019 8:57 AM
  • Same issue, same solution. It only works in debug mode if Visual studio runs as Admin.
    Friday, May 24, 2019 9:11 AM
  • That's interesting because it suggests that this is a permissions problem in loading these assemblies.   Of course, that's what the "Access is Denied" error message is trying to tell us. However, my customers cannot run my product as Admin because they are just ordinary end users running a packaged desktop application.  Running Visual Studio as Admin is not a solution for these end users because they are not running Visual Studio at all.   So what you are seeing is a an exception that is happening as you load and run code under Visual Studio, whereas what I am seeing is happening after I compile, package, and ship to an end user who runs code under his own limited permissions.  He has no notion of Visual Studio.  The only solution that works for these end users is for me to embed the Interop assemblies into my assemblies.  That fixes the problem 100% of the time.

    Thanks for the information.   If I learn more about the root cause, I'l post it here.


    ...Jim Black



    Friday, May 24, 2019 2:45 PM
  • Thanks for the information.  See my answer below to aamtest to give more context of my predicament.   We have seen this on 5-10 customer installations of W10 around the world, and these customers do not have the option of running our application as administrator because their IT department does not give them Admin privileges.  The only solution we can deploy is the embedding of the Interop assemblies into our assemblies, which may be clumsy, but we have no choice at this point.

    Thanks for your information and please post further if you learn more about this.


    ...Jim Black



    Friday, May 24, 2019 2:49 PM
  • Here's an update on this problem.   Since March 2019, we've had roughly twenty end users report a fatal "access denied" exception when our app attempts to load the Primary Interop Assemblies (PIA) for Microsoft Project. We ship the MS Project and MS Excel PIAs with our application and place them in the binaries folder of our application.  We do not attempt to put them in the GAC nor do we rely on their being present in the GAC.

    In every case, if we ship the user a special build in which we no longer ship the PIAs but instead embed COM Interop  into our assemblies, the problem goes away.  It appears that Microsoft is deprecating the production and shipping of PIAs.  They stopped producing standard PIAs after Office 2013 and seem to be pushing us to use embedded interop instead.  There's a good StackOverflow discussion of this which includes admonition from Hans Passant to abandon PIAs in favor of embedded Interop.

    The really nasty practical gotcha is that obfuscation starts giving runtime failures when you embed interop.  This is because Microsoft's implementation of embedded interop makes heavy use of dynamic variables to map the COM variant types.  Dynamic types as function arguments are a real challenge to obfuscation technology.

    By the way, I've never reproduced this problem in our lab.   I'm beginning to suspect that the culprit is some anti-malware that is now built into Windows 10 or Office 365.  Such anti-malware could be detecting our attempt to load the PIA and deciding that it is the signature of a malware attack.  I'd love to learn more about this theory.



    ...Jim Black


    Monday, July 8, 2019 4:58 PM
  • Hi Jim,

    I am so glad I found your post. I'm currently running into a very similar situation with my app as well, but in regards to Microsoft.Office.Interop.Word PIA. Our exception isn't an access one, but I wonder if it's related in some way. The similarities lie in that we cannot reproduce ever, it doesn't happen to the majority of users, and a repair of office fixes it for a few days and then it comes back again. What's weird is I've confirmed we already embed the Office PIA's, as they actually embed by default in Visual Studio. Our Word add in fails to load because of the following exception:

    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Method 'add_DocumentBeforeSave' of COM event interface 'Microsoft.Office.Interop.Word.ApplicationEvents4_Event' is not present on event provider 'Microsoft.Office.Interop.Word.ApplicationEvents4'.

    Which doesn't make any sense as I've taken their Word PIA from the GAC and inspected the dll and I see the method is in fact on the event provider, which to me only seems to indicate an issue with the embedded assembly. 

    Were you able to find anything else in regards to why your users we're seeing these issues? 

    Thursday, July 25, 2019 3:12 PM
  • Hi.  I answered your questions under your post rather than here.   To answer your question about the MS Project issues, we have learned nothing new about the root cause, but we have observed that embedding the PIA into our assemblies has made the error reports from the field stop occurring.  So we're guessing/hoping that embedding the interop did the trick.  That doesn't help you, I know.

    ...Jim Black

    Thursday, July 25, 2019 3:52 PM
  • We use the PIAs, too, and noticed the same error messages for any user that had the following happen:

    --Purchased a new PC from a vendor with the Windows 10 image pre-installed (version 1809)

    OR

    --Updated their Windows 10 to version 1809 and then started using the version 1906 updates for Office 2016, Office 2019 and Office 365

    Evidently, they deprecated all of the 2010 PIA interops without a big notice to Gold Partners. We are using the same workaround as you (embedded in our code so we do not rely on MS location) and moved up to the 2013 PIA. 

    Kind of a disappointment because we have a large number of clients and this has already affected hundreds of machines for our existing clients. We made a special announcement to let folks know that our 2019 version works "out of the box" with the MSO products using the latest versions of Windows 10.

    edit: corrected some awkward phrasing


    Monday, July 29, 2019 10:21 PM
  • Hi Teefer,

    Thanks for posting the information about your experience.  It confirms that Microsoft has done something in Windows 10 or in Office to break what used to work.  I'm glad that our workaround worked for you, too.   It sure would be nice if Microsoft would let its partners know what is going on with these breakages.  Maybe if we keep posting to this question, it will become clearer to us.


    ...Jim Black

    Monday, July 29, 2019 10:36 PM
  • Here's a very relevant thread in Technet that is pointing the finger at the assembly Office.dll, which is used by basically all integrations with Microsoft Office, including ours (MS Project) and jmillerim2 (MS Word).

    ...Jim Black

    Friday, August 23, 2019 5:53 PM