none
problems when deploying for different versions of Office RRS feed

  • Question

  • Hi,

    I’m developing an integrated Office program based on a Word template and an Access database. It should work with different Office versions from 2007 to 2016. I wrote an Inno Setup script for installation; it will download Access Runtime 2010 if Access is not installed on user’s computer.

    At the moment, I developed in Office 2013.

    My Access project has the following references:

    1. Visual Basic For Application
    2. Microsoft Access 15.0 Object Library
    3. OLE Automation
    4. Microsoft Office 15.0 Access database engine Objet Library
    5. Microsoft Scripting Runtime
    6. Microsoft Word 15.0 Object Library
    7. Microsoft Office 15.0 Object Library

     My Word project has the following references:

    1. Visual Basic For Application
    2. Microsoft Word 15.0 Object Library
    3. OLE Automation
    4. Microsoft Office 15.0 Object Library
    5. Microsoft Forms 2.0 Object Library
    6. Microsoft Scripting Runtime
    7. Microsoft Access 15.0 Object Library

     I’m hitting on the usual different versions problems.

    From what I read on the net and from my experience, I reached the conclusion that I should deliver:

    • the Word template created in the last existing Office version (2016)
    • the Access database created in the first Office version (2007)

    It strikes me that the compatibility problems are solved in opposite directions!

    I experienced that all the references in the Word project developed in the last version are correctly updated when installed in all the precedent Office versions.

    The major problems occur in Access. The database developed in Access 2013 when installed in:

    • a system with Office 2010, the reference to Microsoft Word 15.0 Object Library is not updated and marked as missing:
    • a system with Office 2007, the database cannot be opened at all and I get the following message: “The database cannot be opened because the VBA project contained in it cannot be read.”

    Indeed, I started to develop in Access 2007 then moved on versions 2010 and 2013. Now I have to find a simple way to export all my database objects to a folder and importing them (selectively to find the culprits) in a blank Access 2007 database. Do you have some suggestions?

    On the net I found several posts advocating the late binding while developing but the late binding when delivering, in order to avoid all references problems.

    But, beside the boring part to rewrite my code to allow the doubled variables declarations based on some constant, I understand that this will solve the problems only with the interoperability routines not with all my code, especially my forms. I’m I right?

    Thanks in advice for any help.

    Lauro

    Sunday, January 15, 2017 10:25 AM

Answers

  • >>It strikes me that the compatibility problems are solved in opposite directions!

    Not sure which way you are disagreeing with. But for word, Access or any office program, you want to work with the lowest version you going to deploy to.

    And not much of a surprise that going “forward” in versions has the best chance of working. I mean, you can run Access 97 (about 20 years old) on a brand new win 10 box. However, back then we were talking window 95, and it been a VERY LONG time since recent versions of office can run on such old computers.

    I mean, if you’re developing in say office 2016, and you by intention (or by accident) use some new feature limited to 2016, then you can’t possibly expect that software to run in previous versions.

    So for a good 20 years, the “general” experience in the computer industry is that going forward works well, and going backwards can be a real mess. So no surprise that you have good luck and experience going forward versions.

    What this means is you want to develop with the LOWEST version of office that you going to deploy with. So while developing with Access 2016 and going back of Access 2007 likely not going to work, the reverse will work in near all cases without issues. So if you develop with Access 2007, then the resulting application will work with 2010, 2013 and 2016.

    >>On the net I found several posts advocating the late binding while developing but the late binding when delivering, in order to avoid all references problems.

    I think in above you meant to say early binding during development, and then switch to late binding for deployment.

    >> I understand that this will solve the problems only with the interoperability routines not with all my code, especially my forms. I’m I right?

    You should not have any issues with all of your code if you go late binding for the basic office suite programs.

    I have some word merge code I run from Access – it has worked un-changed from about Access 2000 onwards without changes for EVERY version since then! And due to late binding, then you can easy run ANY version of Access with ANY version of word – from word 2000 onwards.

    Once such automation code is debugged (using early binding) and you have it all running well, then you change that code to run as late binding. And since changes to such code likely is “little” or very “minor” once you have such automation code working, then often minor tweaks etc. can easily occur with late binding.

    So in Access, you likely want to remove the reference to word (and switch that code to late binding). And same goes for the scripting runtime.

    Once you done above, then that Access application will run with 2007 onwards – and work with any version of word installed.

    And same goes for your word project. You want to remove the reference to Access, and also the scripting runtime. (switch that code to late binding). The Forms 2.0 "should" be ok.

    With above references removed, then you have a very good chance that the applications will run without issues from office 2007 all the way to 2016 – and run without you having to change any code at all.

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

    • Marked as answer by Lauro2 Saturday, January 28, 2017 7:11 PM
    Tuesday, January 17, 2017 1:12 AM
  • One other thought also came to me, does your setup script create a Trusted Location for the database front-end?

    Daniel Pineault, 2010-2016 Microsoft MVP Professional Support: http://www.cardaconsultants.com MS Access Tips and Code Samples: http://www.devhut.net

    • Marked as answer by Lauro2 Saturday, January 28, 2017 7:11 PM
    Tuesday, January 17, 2017 3:04 AM
  • >>I decide to use late binding I should put in every module and form a costant

    When developing, you could use code above.

    It would be convenient for you to use intellisense function in early binding and you could write late binding code according to early binding code, but it makes your code large.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Lauro2 Saturday, January 28, 2017 7:10 PM
    Wednesday, January 25, 2017 9:02 AM
    Moderator

All replies

  • >>It strikes me that the compatibility problems are solved in opposite directions!

    Not sure which way you are disagreeing with. But for word, Access or any office program, you want to work with the lowest version you going to deploy to.

    And not much of a surprise that going “forward” in versions has the best chance of working. I mean, you can run Access 97 (about 20 years old) on a brand new win 10 box. However, back then we were talking window 95, and it been a VERY LONG time since recent versions of office can run on such old computers.

    I mean, if you’re developing in say office 2016, and you by intention (or by accident) use some new feature limited to 2016, then you can’t possibly expect that software to run in previous versions.

    So for a good 20 years, the “general” experience in the computer industry is that going forward works well, and going backwards can be a real mess. So no surprise that you have good luck and experience going forward versions.

    What this means is you want to develop with the LOWEST version of office that you going to deploy with. So while developing with Access 2016 and going back of Access 2007 likely not going to work, the reverse will work in near all cases without issues. So if you develop with Access 2007, then the resulting application will work with 2010, 2013 and 2016.

    >>On the net I found several posts advocating the late binding while developing but the late binding when delivering, in order to avoid all references problems.

    I think in above you meant to say early binding during development, and then switch to late binding for deployment.

    >> I understand that this will solve the problems only with the interoperability routines not with all my code, especially my forms. I’m I right?

    You should not have any issues with all of your code if you go late binding for the basic office suite programs.

    I have some word merge code I run from Access – it has worked un-changed from about Access 2000 onwards without changes for EVERY version since then! And due to late binding, then you can easy run ANY version of Access with ANY version of word – from word 2000 onwards.

    Once such automation code is debugged (using early binding) and you have it all running well, then you change that code to run as late binding. And since changes to such code likely is “little” or very “minor” once you have such automation code working, then often minor tweaks etc. can easily occur with late binding.

    So in Access, you likely want to remove the reference to word (and switch that code to late binding). And same goes for the scripting runtime.

    Once you done above, then that Access application will run with 2007 onwards – and work with any version of word installed.

    And same goes for your word project. You want to remove the reference to Access, and also the scripting runtime. (switch that code to late binding). The Forms 2.0 "should" be ok.

    With above references removed, then you have a very good chance that the applications will run without issues from office 2007 all the way to 2016 – and run without you having to change any code at all.

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

    • Marked as answer by Lauro2 Saturday, January 28, 2017 7:11 PM
    Tuesday, January 17, 2017 1:12 AM
  • I'd urge you to convert your code over to Late Binding thus not requiring any Word reference libraries.

    As with any development, you need to always perform your development using the oldest version that will be used to run your program.  Thus, if you have users running Access 2007, then you need to perform all your development in Access 2007.  Access (and other office applications) will automatically update your Ref libraries moving forward, but the inverse is not true and thus your errors.

    Another, recommendation is to use virtual machines for testing purposes.

    As for errors with your forms, we'd need more information.  But it's most probably related to the issue with developing your db on a more recent version than it is being run on and thus reference library issues.


    Daniel Pineault, 2010-2016 Microsoft MVP Professional Support: http://www.cardaconsultants.com MS Access Tips and Code Samples: http://www.devhut.net


    Tuesday, January 17, 2017 2:27 AM
  • One other thought also came to me, does your setup script create a Trusted Location for the database front-end?

    Daniel Pineault, 2010-2016 Microsoft MVP Professional Support: http://www.cardaconsultants.com MS Access Tips and Code Samples: http://www.devhut.net

    • Marked as answer by Lauro2 Saturday, January 28, 2017 7:11 PM
    Tuesday, January 17, 2017 3:04 AM
  • Thank you Albert for your answer.

    What it strikes me is that Access and Word don't seem to work in the same way between different versions.

    I agree that is more usual and simpler that a project developed with an old version would work fine in a new version then the other way around.

    But:

    • A template made in Word 2013 works perfectly fine in Word 2007 (if you didn't use new features). A template developed in Word 2007 has the annoying notice in the window bar : "Compatibility mode". So it seems better to develop with the last version in Word.
    • A database developed in Access 2013 doesn't seem to open in Access 2007 even if you didn't use new feature. Or at least is very difficult to understand which new feature you inadvertently used.
    • In Word 2013 you can save in an older format. It only tell you that new features will non be saved.
    • The same is not possible in Access. And will be very usuful. Why should I buy a new version if I cannot use it?

    As for early or late binding I didn't understand very well if you are advocating the late binding always to avoid all version problems or not.

    Thans, Lauro



    • Edited by Lauro2 Tuesday, January 17, 2017 5:55 PM
    Tuesday, January 17, 2017 5:49 PM
  • "What it strikes me is that Access and Word don't seem to work in the same way between different versions."

    That is not the case.  The same is true for any Office application (Access, Excel, PowerPoint, Word, ...).  The only reason you're not experiencing any issues with your template, is that your template does not use any extra Reference Libraries that you added.  Go ahead and add a Reference Library to Excel or Access and then try porting it to Word 2007 and you'll get errors.

     

    "As for early or late binding I didn't understand very well if you are advocating the late binding always to avoid all version problems or not."

    Use Early Binding to ease development and then switch it to Late Binding when deploying it.  It is usually very straightforward to convert.


    Daniel Pineault, 2010-2016 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net


    Tuesday, January 17, 2017 5:59 PM
  • Thank you Daniel for you answer.

    If I decide to use late binding in Acces I will solve the problems of the references to a specific version of Word, but I will not solve the problems between different version of Access, right?

    I I decide to use late binding I should put in every module and form a costant,

    #Const wDebug = False
    '#Const wDebug = True
    

    and in each declartion of my routines something like

    #If wDebug Then
        Dim wApp As Word.Application
    #Else
        Dim wApp As Object
    #End If
    

    And swich between the two values of the constant.

    Right?

    >Another, recommendation is to use virtual machines for testing purposes.

    Until now I was swiching between different computers, but maybe it will be simpler to have virtual machines on the same computer. I never used them.  Are they simple? Do you have any suggestions about how to do

    >One other thought also came to me, does your setup script create a Trusted Location for the database front-end?

    Yes it does.

    Thanks, Lauro

    Tuesday, January 17, 2017 6:13 PM
  • >>I decide to use late binding I should put in every module and form a costant

    When developing, you could use code above.

    It would be convenient for you to use intellisense function in early binding and you could write late binding code according to early binding code, but it makes your code large.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Lauro2 Saturday, January 28, 2017 7:10 PM
    Wednesday, January 25, 2017 9:02 AM
    Moderator
  • Thanks Celeste, Daniel and Albert for your help.

    I'm changing my code to be able to switch easely from early to late binding using a #Const.

    I removed the "Microsoft Access XX.0 Object Library" in my Word, that obliges me to change the code in only one module.

    I removed the "Microsoft Word XX.0 Object Library" in my Access, that obliges me to change the code in several modules; I will try to put most of the code in few modules.

    Should I remove also the references to "Microsoft Office XX.0 Object Library" in both Word and Access? I started and I saw that I should put all the callbacks for my ribbon in the conditional statements cause  the variable "Public gMyRibbon As IRibbonUI". Is it safe and correct?

    What about the other references?

    1. Visual Basic For Application
    2. OLE Automation
    3. Microsoft Office 15.0 Access database engine Objet Library
    4. Microsoft Scripting Runtime
    5. Microsoft Forms 2.0 Object Library
    Thanks again, Lauro

    Friday, February 10, 2017 9:49 AM