Results 1 to 12 of 12
  1. #1
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10

    Lightbulb Unanswered: Access -> Runtime using Visual Studio tols 2005

    I have completed a project in MSAccess for a client who is keen to have it as a stand-alone application (buying visual studio tools 2005 instead of 10 liscences for MSAccess) - so I have done some investigation but I still have a few unanswered questions:

    My program needs Microsoft Office Object Library 10.0 (or above) which I have turned on using VBA on project load. Will this will cause problems when it becomes a RT app?

    Custom toolbars - will my custom toolbar be available in Runtime?

    What other issues should I be looking for? I have obvious reservations about spending 160 of my clients money on something that may not work with the system I have built.

    Thanks in advance!

    - GeorgeV
    George
    Home | Blog

  2. #2
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Bumpety, bump, bump
    George
    Home | Blog

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    its a long time since I configured a version of runtime, so its a bit hazy.. most of the access stuff i do that requires runtime is passed over to QA / App support as 'their' problem, after all its their setup that requires runtime, so its 'their' issue to correctly configure runtime in my view.

    when you configure your runtime environment you will be setting which libraries your application requires as part of that configuration. I know it can be a problem if you change some of the libraries (not a biggie just app support have to rebuild the runtime environment to incorporate the new libraries). Its always a smart idea to make sure that you tell them in advance what libraries you are using though. The choice of office 10 or office whatever is laregly irrelevant... runtime will use the office library it ships with.

    so the first thing to do is build the environemnt and thoroughly test all aspects of the app. From what I remember things like custom toolbars are part of your projects design, so they too should come through with the MDE. One thing you may need to be carefull of is making assumptions about what features are always available.. because they are part of Access and may not be part of runtime by default.
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    I have performed every test under the sun on this project and am planning to run them again when/if it becomes a RT app.

    I was worried about the code in my application for turning on references - but if you think the DLL is "packaged" up with the app then I'm happy!

    If you want I can send you a simple version of the program.
    If not - dw
    thanks for the reply - sounds like I should just go ahead and buy the product and give it a go really.

    Wish me luck!
    George
    Home | Blog

  5. #5
    Join Date
    Mar 2002
    Location
    Bielefeld, Germany
    Posts
    69
    Do you have the Office Developer Edition? If not, that is the right thing to invest into if you are trying to built runtime environments. I'm not really sure why you would need VST2005 as with the developer edition, you can build packages that incorporate the Access runtime and everything your app needs.
    In any case, you have to test your package thouroughly and the two main culprits from my expirience are dependency problems and already installed office packages on the target computers. For the latter, you should make sure that the runtime is NOT installed in the default directory but somewhere else. Otherwise, your runtime could break a present access instalation or a later installed Access might break your runtime. For the dependencies, that is highly dependend on your app.

  6. #6
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    I was thinking of VST2005 because that's what google advised

    I can see myself having to delete alot of my lovely code (such as the call that checks the version of access running).

    By the sound of thngs I think my only issue with this will be the Object Library.

    I've attached the part of the project that I think will cause problems - feel free to have a poke around.

    There's some cute/clever bits in there IMHO

    Try importing the *.ORD file (csv file with different extension)
    Attached Files Attached Files
    George
    Home | Blog

  7. #7
    Join Date
    Mar 2002
    Location
    Bielefeld, Germany
    Posts
    69
    The Microsoft Office Object Library is part of the Access runtime. The filename is MSO.DLL. When you install the runtime (or the whole office, for that matter), it is installed under <%programdir%>\shared\Microsoft Shared\Office<version>\MSO.DLL.
    Keep in mind that you need to have Microsoft Office XP Developer Edition or Microsoft Access 2003 Developer Extensions (which are also part of Visual Studio Tools for Office) to have the right to redistribute the runtime. see here: http://office.microsoft.com/en-us/ac...208861033.aspx

  8. #8
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Quote Originally Posted by chrisp_999
    The Microsoft Office Object Library is part of the Access runtime.
    But MSOOL is not built into Access? *confused*
    Quote Originally Posted by chrisp_999
    Microsoft Office XP Developer Edition or Microsoft Access 2003 Developer Extensions (which are also part of Visual Studio Tools for Office) to have the right to redistribute the runtime
    So I have to have this, not them?
    George
    Home | Blog

  9. #9
    Join Date
    Mar 2002
    Location
    Bielefeld, Germany
    Posts
    69
    No, it's not built in-it's a library ;-). You only need a reference to it when you use some of the objects it provides. So it is not referenced by default even though it is part of the runtime distributable and the access package.

    And yes, you have to have that, not your customer. Iirc, even if they had the developer edition, they are not allowed to package _your_ app with _their_ developer license. The EULA only permits to package your own apps (I'm not sure if that is still true for the more recent versions of Office, but it used to be that way back when I started developing in access and from a MS point of view, it makes sense).
    But of course, your customer can pay the developer licence for you :-D.

  10. #10
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Even if the client doesn't have Office installed?

    Yeah, I won't be paying for the liscencing and I have copies of what's needed
    George
    Home | Blog

  11. #11
    Join Date
    Mar 2002
    Location
    Bielefeld, Germany
    Posts
    69
    As I said, MSO.DLL is included in Access runtime. So if you install the runtime, MSO.DLL will be installed also, regardless wether there there are other parts of Office present or not.
    But the best thing to do is to generate a package of your app and test it on a clean windows install, anyway. And as a second step, test it on one of the clients computers before roll out.

  12. #12
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Thanks for the answers chrisp
    I feel much more confident in my arguement for a run-time app saving money for my client!
    George
    Home | Blog

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •