Forum Discussion

rsippel's avatar
rsippel
Occasional Contributor
14 years ago

Can we automate setup and reloading of CLR Bridge and path to Extensions?

We want to allow our clients to run our tests without them having to know how to customize all the details (such as insuring that certain items are in the ClrBridge list for the project, or that the proper Extensions\bin is being referred to by TestComplete/TestExecute). The less that they have to do the better. Ideally, they should only have to run some installation program for the project, and then run some batch-file whenever they want to run the project, and then view the results. They should not have to be concerned in any way with tweaking the system so that TestComplete or TestExecute can find things.



Our environment is one in which we may be switching between projects and/or versions of projects often. Two common issues that seem to come up are:

* the need to go into TC's [Tools]>[Options]>[Engines]>[Script Extensions] to adjust the path so that TC/TE can find our extensions for that project and insure that they are reloaded.

* the need to go into TC's [Tools]>[Current Project Properties]>[CLR Bridge] to insure that desired items are in the list and are reloaded. Each project may have different items in their lists.



Is there any way to have access to the ClrBridge from within a script so that we can alter it and reload it (e.g. during initialization) to insure that it is automatically adjusted and up-to-date for the environment that the project is being run in?



Is there some way to automate this sort of thing (via a batch-file or creating an exe or ...) so that it could be included in either the project-installation code or in the batch-file used to run the project?



Thanks


  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    14 years ago
    * the need to go into TC's [Tools]>[Options]>[Engines]>[Script Extensions] to adjust the path so that TC/TE can find our extensions for that project and insure that they are reloaded.




    Whatever means you have to install the project on the client workstation, any script extensions would simply need to be dropped into the Bin\Extensions\ScriptExtensions folder.  Script extensions are universal for any instance of TestComplete so, once they are there, you can run any number of projects, all using the same script extensions.  Script extensions were, as far as I can gather, intended to be non-project specific but a way of creating universally useful code for any project you may be developing or running. 



    * the need to go into TC's [Tools]>[Current Project Properties]>[CLR Bridge] to insure that desired items are in the list and are reloaded. Each project may have different items in their lists.
     



    This information is saved in the MDS file of the project.  So, once you have created and packaged your project, there is no need to redefine this information..


  • rsippel's avatar
    rsippel
    Occasional Contributor
    14 years ago

    Thanks for the prompt reply.


    Re: extensions. We have written our own extensions as well as making use of extensions from 3rd parties. It seems to me that your answer is the approach that we use when dealing with the 3rd party extensions. We use the same 3rd party extensions for all of our projects/suites. We never have to deal with 3rd party extensions via TC's [Tools]>[Options]>[Engines]>[Script Extensions] page because they don't change very often and can be stored in [...\Bin\Extensions\ScriptExtensions] as you said. That's easy.


    However, it's a different story when it comes to our own extensions. We generally have multiple sandboxes on our machines. One sandbox may contain the current release version of our projects/suites and one (or more) sandboxes may contain projects/suites that are under development. Each sandbox is meant to be "self-contained", so each has its own version of our extensions. We have to use TC's [Tools]>[Options]>[Engines]>[Script Extensions] page to specify where our extensions are. Every time that we switch from one sandbox to another we need to go to the [Script Extensions] page and change the path to our extensions folder in the sandbox that we are currently working in. If we forget to do that then we can easily run into problems since the extensions being used belong to a different sandbox than the one that we are working on. The [Script Extensions] page applies to TC and not specifically to the currently loaded project/suite, so switching to a project that is in a different sandbox does not automatically switch to the extensions that are found in that sandbox.


    Copying our extensions to [...\Bin\Extensions\ScriptExtensions] is not the answer (unless we set something up to copy the extension files from the sandbox to [ScriptExtensions] every time that we switch sandboxes. Yuck. We'd also still have to somehow reload/refresh the extensions after the copy, which would probably have to be done manually via [File]>[Install Script Extensions...]>[Reload].


    I don't think that the [Script Extensions] page even allows you to use relative paths (though I may be mistaken). I guess that the question would be "relative to what?". If you change projects then you are changing your location and wouldn't that then necessitate recalculating the provided relative-path to your extensions? Since it is TC-related instead of project-related, I would think the relative path (if allowed) would have to be relative to the TC-folders rather than the project-folders.


    When our clients install our projects/suites, they create their own sandboxes. We have no control over (and don't want to try to limit them) what the sandbox paths are. They also may have multiple versions of our tests (since they are testing multiple versions of their software). It would be wonderful if there were some flexible way to have the tests run without them having to tweak TC first so that our extensions could be found.


    So, my original question was trying to find some way to automatically adjust the location where TC expects to find our extensions when we switch/load projects. It does not sound like TC can do this though it seems like it is a logical concept to investigate.

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    14 years ago
    Script extensions are essentially the same things as plug ins.  They are part of the IDE environment.  It would be like writing code in Delphi XE to create a new component, add it to the IDE environment, and use it in the application all during the compilation the application.