locked
TF84037: There was a problem initializing the Microsoft Excel Team Foundation AddIn. Re-installing the Team Foundation Client may be required. RRS feed

  • Question

  • Out of the blue a perfectly functional solution now throws this error when the binary runs. Googling has helped nothing at all. Some solutions posted, but no explanations as to how or why this should spontaneously happen (I have a weekly run of a report generations system which just fell over this week).

    I can't identify a change at all.

    So I open the solution in VS2008 to examine and try a rebuild, and what do I see? Two of the referenced DLLs have little exclamation points against them and I cannot build. The two libraries are:

    Microsoft.Office.Core (Microsoft Office 12.0 Object Library)
    VBIDE (Microsoft Visual Basic for Applications Extensibility 5.3)

    A build attempt reports:

    Warning    17    Found conflicts between different versions of the same dependent assembly.   
    Warning    18    The referenced component 'Microsoft.Office.Core' could not be found.    
    Warning    19    The referenced component 'VBIDE' could not be found.    

    Warning 17 frustrates me as it doesn't tell me which assembly and what the conflicting version numbers are or provide any traction on the issue.

    Exploring warnings 18 and 19 manually suggests they are simply untrue.  Let me explain.

    On the references in VS2008 I examine properties. From these I can find GUID in the Identity property. By scanning my registry for that GUID, in no time at all I have a path to the DLL. I examine my hard drive and the referenced DLL exists (as I expect it does, as it always did and nothing was changed to my knowledge).

    So what does the exclamation point mean? And how to diagnose it further?

    I can also try this:

    1) Remove the broken reference
    2) Add it again (the two libraries appear on the list presented on the COM tab of the Add Reference dialog box in VS2008)
    3) Voila, it's added, but with yellow exclamation point still.

    What is going on? How to diagnose it further? Such crytpic and useless feedback from VS2008 is frustrating?

    Did a windows XP update in the week between cause this? We have automatic updates here and I don't know if one happened or not? What could have caused this? It would be easier to say if we knew exactly what "this" is? All I know is my app is broken and I'm clueless as to why or how to further diagnose it. The very definition of a furstrated geek!

    Bernd.

    P.S. Choosing where to post this was a dilemma. I accept feedback based on perceived areas of concern. My supposition is I need help with the C# IDE to diagnose what the actual problem here is, to be able to build my app. The C# IDE seems, frankly, to have a serious weakness here and I wonder what diagnostic tools are or methods are available to me to diagnose what is actually wrong with my solution! To my mind a C# IDE issue, but I accept feedback and will happily relocate this question to another forum if it's more likely to yield fruit there!


    Project Manager, Manager of Support, Quality Assurance and Documentation
    Wednesday, January 27, 2010 5:23 AM

Answers

  • Well, well. Scratched my head for ages on this and am in no way really pleased with the outcome. My main gripe is the lack of lucidity around diagnosis, understanding causes and what was broken. Michael's tips were well received and  I wish I could have learned more from MS-Buils's output, but in the end this problem was resolved simply by reinstalling the Office Primary INterop Assemblies for both office 2003 and 2007. The project now builds, and runs as it always did.

    While I'm glad of that, I remain frustrated that MS-Build doesn't provide some more lucid indicators as to what was wrong than I have shared below. I can see now visible change to my filesystem (GAC) and am left suspecting that something in the registry changed when I reinstalled the PIAs (i.e. went broken for some other reason last week). But without expending significant effort on diagnosis I'll not know and may in fact never be able to know (as I probably cannot reproduce the problem anymore and don't have registry snapshots before and after the reinstall).

    Ignorance (mine) alas, irritates me and I wish I understood how the references in my project worked, precisely upon what they depend and what might go wrong and did go wrong. But these questions are moot. The problem is resolved.

    Project Manager, Manager of Support, Quality Assurance and Documentation
    • Marked as answer by Bernd Wechner Thursday, January 28, 2010 12:48 AM
    Thursday, January 28, 2010 12:48 AM

All replies

  • I'm unclear as to when you are getting the error message you're getting.  Are you running an app that you compiled and you get this error message, do you get this error message when VS starts up, etc?  The error itself is related to TFS so if it is occurring outside VS then that would strike me as odd.

    What type of project do you have?  Are you running SP1?

    Right-click each of the problem references.  What runtime version are they targeting?  Does that line up with what your application is trying to use?  Modify the build settings via Tools\Options -> Projects & Solutions\Build and Run.  Set the MSBuild output setting to Detailed and you'll get a log of the gory details.  The COM resolution occurs in the ResolveComReference task.  Within there you'll see the lookup process and should be able to detect any errors.

    Michael Taylor - 1/27/10
    http://p3net.mvps.org
    Wednesday, January 27, 2010 2:55 PM
    Moderator
  • Michael,

    This relates to a solution I have which reads TFS and uses MS-Office (notably excel) to prepare some graphs form what it finds in the TFS work item store.

    It's worked reliably for a half year or more. And suddenly failed.

    It runs in two contexts (two distinct projects in the solution):

    1) As a command line program
    2) As a VS2008 Addin (which adds a tool bar which has a button which I click to do what the command line would do ;-).

    The reasons for that split are entirely historical (the command line tool evolved from a set of smaller tools in the VS2008 Addin)

    Now in that context:

    1) The command line version just hangs. Which is why I turned to the other to diagnose.
    2) I can't build the VS2008 Add-in (or the command line version for that matter) because of these broken references
    3) I can run the existing build of the VS2008 Add-in and it produces this message (TF84037).

    My main mission is to be able to build. Would not be half surprised if the run time issues disappeared at the same time (given the build problem relates to DLLs),

    So I thank you deeply for the advice regarding MSBuild output. I have gone one step further and set it to Diagnostic. The relevant snippet or output I can identify is:

    Target "ResolveComReferences" in file "c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets":
      Task "ResolveComReference"
        Resolving COM reference for item "Microsoft.Office.Core" with a wrapper "primary".
        Determining dependencies of the COM reference "Microsoft.Office.Core".
        Resolving COM reference dependency "00020430-0000-0000-c000-000000000046" version 2.0.
        Resolved COM reference dependency "00020430-0000-0000-c000-000000000046" version 2.0: "C:\WINDOWS\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll"
        c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3283: Cannot find wrapper assembly for type library "Microsoft.Office.Core".
        Resolving COM reference for item "VBIDE" with a wrapper "primary".
        Determining dependencies of the COM reference "VBIDE".
        c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3283: Cannot find wrapper assembly for type library "VBIDE".
      Done executing task "ResolveComReference".

    What interests me is:

    1) the DLL "C:\WINDOWS\assembly\GAC\stdole\7.0.3300.0__b03f5f7f11d50a3a\stdole.dll" exists on my system.
    2) I am confused by the different messages above for the two DLLs (Microsoft.Office.Core and VBIDE). The former mentions a DLL in my file system (stdole.dll) and the latter does not.
    3) I am still not clear what "Cannot find wrapper assembly for type library" specifically means, in terms of what is wrong, could have gone wrong or how to fix it.

    I'll google around a bit on that last item. Wanted to reply with what I know now in case some insights emerge here.

    Thanks very much for the direction thus far!

    Bernd.

    Project Manager, Manager of Support, Quality Assurance and Documentation
    Wednesday, January 27, 2010 10:05 PM
  • Well, well. Scratched my head for ages on this and am in no way really pleased with the outcome. My main gripe is the lack of lucidity around diagnosis, understanding causes and what was broken. Michael's tips were well received and  I wish I could have learned more from MS-Buils's output, but in the end this problem was resolved simply by reinstalling the Office Primary INterop Assemblies for both office 2003 and 2007. The project now builds, and runs as it always did.

    While I'm glad of that, I remain frustrated that MS-Build doesn't provide some more lucid indicators as to what was wrong than I have shared below. I can see now visible change to my filesystem (GAC) and am left suspecting that something in the registry changed when I reinstalled the PIAs (i.e. went broken for some other reason last week). But without expending significant effort on diagnosis I'll not know and may in fact never be able to know (as I probably cannot reproduce the problem anymore and don't have registry snapshots before and after the reinstall).

    Ignorance (mine) alas, irritates me and I wish I understood how the references in my project worked, precisely upon what they depend and what might go wrong and did go wrong. But these questions are moot. The problem is resolved.

    Project Manager, Manager of Support, Quality Assurance and Documentation
    • Marked as answer by Bernd Wechner Thursday, January 28, 2010 12:48 AM
    Thursday, January 28, 2010 12:48 AM