none
build errors after switch to 365 RRS feed

  • Question

  • I have a development program written with Visual Studio 2013. After switching to Office 365, I started receiving "There were build errors. Would you like to continue and run the last successful build." There are no errors listed.    One of the warnings is "Cannot find wrapper assembly for type library "Microsoft.Office.Core"    Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component.   For example, if the COM component is 32-bit, your target platform must not be 64-bit.     How do I do this?   It was working fine before the update to 365, but that doesn't have to be the issue.  

    My output tells me that build failed and gives warning MSB3283 related to the Microsoft office core.

    • Edited by jjobcorp Saturday, March 14, 2015 9:55 PM
    Saturday, March 14, 2015 9:28 PM

Answers

  • So the reference you need for office is this:

    Notice in above I have
    office 11 (Office 2003)
    office 14 (office 2010) (the one I selected in above)
    Office 15 (office 2013)

    And in a fact I do have all 3 versions of office installed. I would consider using late binding if you looking to support “any recent” version of office and a "particular" program like word installed.

    In fact just using office “inter-op” in VS should do this. So it not quite clear what you have (or require) in your VS project that is “specific” to a given version of office, but if using office core, then you need to reference a "particular" version of office.  I would STRONG recommend you figure out a way to eliminate this dependency in your project .


    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    • Marked as answer by jjobcorp Sunday, March 15, 2015 2:17 PM
    Sunday, March 15, 2015 12:59 AM

All replies

  • Check the bitness of your Office installation: File > Account > About.

    Is it the same as your program?

    Unless you really, really know what you are doing, both should be 32-bit, even on a 64-bit OS.


    -Tom. Microsoft Access MVP

    Saturday, March 14, 2015 9:55 PM
  • I found the bitness at the top and it is 32 bit.     How do I check on the bitness of Visual Studio?   If it is through Build configuration manager, this is set to x86

    I still feel this is related to 365 due to the output message



    • Edited by jjobcorp Saturday, March 14, 2015 10:55 PM
    Saturday, March 14, 2015 10:06 PM
  • In Build -->configure, make sure you “add” a new  config and use x86.

    You should thus have this:

    AFTER you have above, now go Project->YourProjectname Properties.

    On compile, you thus should have this:

    To get the “core” compounent, then you simply need to reference the given installed version of office. You don’t mention what version of office. EACH office has a number.

    So assuming office 2010, then that is office 14, and under “COM” references for your project you need to reference the Microsoft Office 14.0 Object library (and 15 if office 2013).

    I will post a screen shot in a “reply” to my own post since each post only allows 2 pictures.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Sunday, March 15, 2015 12:57 AM
  • So the reference you need for office is this:

    Notice in above I have
    office 11 (Office 2003)
    office 14 (office 2010) (the one I selected in above)
    Office 15 (office 2013)

    And in a fact I do have all 3 versions of office installed. I would consider using late binding if you looking to support “any recent” version of office and a "particular" program like word installed.

    In fact just using office “inter-op” in VS should do this. So it not quite clear what you have (or require) in your VS project that is “specific” to a given version of office, but if using office core, then you need to reference a "particular" version of office.  I would STRONG recommend you figure out a way to eliminate this dependency in your project .


    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    • Marked as answer by jjobcorp Sunday, March 15, 2015 2:17 PM
    Sunday, March 15, 2015 12:59 AM
  • This was absolutely the answer. When I upgraded to Office 365 (which I believe will always update to the latest version), I had not changed from Office 14.

    I hear your recommendation that I figure out a way to eliminate this dependency.    My question would be how I would take data to an Excel spreadsheed without this dependency.   I am wide open to ideas.

    Thanks a million

    Sunday, March 15, 2015 2:21 PM
  • It really depends on the “how” and what you are doing with Excel.

    However, if you simply creating an “instance” of Excel (or grabbing an existing running copy), then simple “create” an instance of that application in code at runtime.

    For example, to create a instance of Excel, and set the first cell to “hello world”, then save the Sheet you could do this in Access VBA (since this a access group!!).

       'Dim myExcel       As Object     ' late binding
       Dim myExcel       As Excel.Application
       Set myExcel = CreateObject("Excel.Application")
       
       Excel.Application.Visible = True
       
       Excel.Workbooks.Add
       Excel.ActiveCell.FormulaR1C1 = "Hello"
       Excel.ActiveWorkbook.SaveAs "c:\Test\MyExcelTest.xlsx"
       
       Excel.Application.Quit
    

    The above code will work UN-CHANGED and can be cut + pasted right into vb.net and vs2013. (the editor will remove the “set” in above, but other then that, the above code works the same in vs2013 with vb.net, or with say Access VBA).

    Note the FIRST line in above (it is commented out). That is late binding. Thus a simple declare of object which can then hold any “COM” automated object such as Excel in this example would be late binding.

    So with “object” commented out, then above code would assume a EARLY BOUND reference to Excel 14. Eg this:

    Note in above that is the VBA reference dialog from Access, but hey this is a Access group! The SAME reference as per the previous screen shots in VS2013 would ALSO allow the above code sample to run. So in place of the “office core” you can simply set a reference DIRECTLY to the given application (in this example Excel). I tend to reference the given application such as word, or Excel, or Outlook.

    ONCE (AFTER) you have the above code working as you please, then you can SWITCH (and should swtich) the above code to late binding.

    Switch to late bind:

    You simply comment out the dim Excel.Application, and use the commented out Object declare on the line below. You ALSO THEN in your project references REMOVE the reference to Excel (or the office core).

    This results in several things:

    Code is now late binding.

    You don’t have a reference to ANY version of Excel, or Office (so ANY installed version will be used when you create the instance of Excel). In fact the code will work with ANY version of Excel the user has installed (going all the way back to Excel 97).

    You WILL LOOSE intel-sense and object syntax checking during development.

    So it is recommended DURING the start of development, you use “early” binding since you get compile time errors, and syntax checking. And in the code editor you get inteli-sense “popup” lists of the properties and methods. Once everything is working, then little if any code changes are required, and you thus flip the code back to late binding.

    Thus once you change to late binding, and remove your reference to the object in question, then no syntax checking will occur during development. (and during compile time).

    I generally find “once” I have the code working as early binding, then one can “switch” to late binding. Later on code changes tend to be VERY minor and thus inteli-sense etc. is not missed.

    If down the road changes to the Excel automaton code will be extensive, then I comment out the late binding object declare, comment in back the Excel.Application declare, and set the reference to the object (excel 14 in this example) and then do my development.

    Once again, before deployment, I always use late binding.

    The end result is your code will run on any computer with any of the last 7 versions of Excel – spanning a 20 year period.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Sunday, March 15, 2015 3:51 PM
  • This is very helpful. Thanks for the post. 
    Wednesday, August 21, 2019 2:38 PM