none
Suddenly seeing failure to load Microsoft.Office.Interop.MSProject assembly related to Office 365 update

    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 Saturday, March 2, 2019 3:31 PM remove duplicate signature
    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