DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 3 of 3

Thread: Fixing references on projects

  1. #1
    Jesse Guest

    Fixing references on projects


    Hi,
    Is there a simple way to recompile all of my VB projects after I make
    a change to a DLL that breaks compatibility. I waste sooo much time
    opening each project and having to reselect references. Can someone
    please help me out.

    Thanks,
    Jesse


  2. #2
    Willy Van den Driessche Guest

    Re: Fixing references on projects

    "Jesse" <Ithacaking@aol.com> wrote in message
    news:3b202701$1@news.devx.com...
    >
    > Hi,
    > Is there a simple way to recompile all of my VB projects after I make
    > a change to a DLL that breaks compatibility. I waste sooo much time
    > opening each project and having to reselect references. Can someone
    > please help me out.
    >
    > Thanks,
    > Jesse
    >


    Out of the same frustration, we actually wrote a little quick and dirty
    program that will do it.
    STEP1:
    For each project we keep an INI file which holds :
    1) The references are their with their full path (ex:
    C:\WINNT\System32\MyDLL.dll)
    2) The target path of the 'package' ex: "e:\bin2\aaa.dll"
    3) The base VB Project name : "e:\src\packagea\a.vbp

    The program is invoked with the INI file as a commandline parameter.
    The program will open the VBP file, throw out all references and put them
    back in itself based on the INI file (use TypeLibInfo to retrieve the GUID
    from a path). We use a temporary VBP file (Temp.VBP)
    Furthermore, if the program detects that the target exists, it will try to
    build it in compatible mode, if now, compatibility is broken and it is just
    built like that. (This amounts to write certain sections in the VBP file
    ourselves).
    Then the program invokes the VB compiler ("d:\program file .....VB6.EXE
    /make Temp.VBP". The VB command line switches allow you to specify an
    output file for all errors. This file is inspected to see if there where
    any errors. If not, the program calls ExitProcess with an errorcode (so
    that you can trap it in batchfiles or makefiles). If everything went OK,
    the existing VBP file is overwritten with the newly created one.

    This allows you to write a simple batchfile to compile all of your projects.
    You must, however manually make sure that they are in the correct order.
    The little program is trivial to write for yourself (the code we wrote is
    not my property). The benefits : you create the INI file once and after
    that you're off. Just invoke the batchfile to build the entire project.
    Delete the targets first if you want to drop compatibility.

    STEP2 (optional)
    Step1 is suffcient for a project with up to 10 or so subprojects. It has a
    significant drawback, however. There is no way for your build process to
    know which components it must compile. We therefore integrated the
    VBCOmpile.EXE program in a makefile. Make is a program with a long history
    perfectly capable of detecting out-of-date targets. Writing a makefile, on
    the other hand is tedious. We therefore wrote a little program that is a VB
    addin. You should open a VB project with correct references. Invoke the
    addin and it will generate a partial makefile for the project. Via 2 loops
    VBProject.Components and in there Files, you can iterate all files used by
    the project. Via references you are able to automatically generate the INI
    file required by VBCompile.
    This approach still has a little problem : if you add files to your project
    you have to manually add them to the makefile or re-invoke the addin.
    For the rest it works fine. For each project we add a make-target to
    compile it, to clean (regsrvr32 -u) it and to register it (if you take it
    out of sourcesafe)
    Since then, we are able to work like a little dream. Believe it or not, but
    we are maintaining 180 components with it and it works. No more broken
    references.

    STEP3(optional)
    It is trivial to extend VBCompile so that it will write some information
    about the compilation process to a little file. We use another global INI
    file for this. We write down the following information (after sucessful
    compilation):
    1. In the section VERSIONS : the current version of the new component
    MyComponent.Dll
    2. In the section MyComponent.Dll : the version numbers of the components
    found in the ini file ( those referenced by MyComponent.Dll). This is
    crucial to help you determine compatibility problems - we have a little
    program that will go and check the versions of those components on any PC.
    It immediately flags out-of-date or wrong-version components by simple
    comparison)
    3. If compiled without compatibility in section BASEVERSIONS : the current
    version of MyComponent.Dll (allows you to see when and where compatibility
    was broken)
    4. The time needed for the compilation, so that we compile the next time we
    can give an estimate of the compilation time.

    We are currently thinking about storing this information in a database so
    that we not only have the information about the latest version, but also all
    previous versions, to be used by the help desk to trace compatibility
    problems)

    Don't be afraid to do this. It 'll work greate and you will have saved
    yourself lots and lots of frustration.
    I am actually thinking about writing a shareware version of this
    functionality but since that could take some time (because it has to be much
    more robust), I wouldn't wait for it.




  3. #3
    L.J. Johnson Guest

    Re: Fixing references on projects

    Jesse,

    > Is there a simple way to recompile all of my VB projects after I make
    > a change to a DLL that breaks compatibility. I waste sooo much time
    > opening each project and having to reselect references. Can someone
    > please help me out.


    Willy has the right idea, but I do have some code you can use at:

    http://mvps.org/st-software/Code/BuildCycle.zip

    The associated article is in the Dec 2000 issue of VBPJ. The code, as it, is
    designed to check out the needed files from VSS, do the compile, then check
    them in again, but it would be trivial to isolate it to just do the compile
    (this is a separate component, and you'd just have to comment out the line
    that calls the other component to check them in).

    "And now for something completely different... Doing builds on a major VB
    project can be a severe pain in various body parts, particularly when
    compatibility is broken fairly regularly on some of the components. The
    included code gives you:"
    a.. A self-installing sample project to test with and
    b.. The code for the two EXEs which you can use to automate the cycle
    c.. A utility to set "No Compatibility" on multiple VB projects.
    "Please read the Readme.txt first before trying any of the code. The idea is
    simple, but the devil really is in the details for this one. The code is
    completely data-driven for ease of change. Based on 3 *.DAT files (text),
    the programs will do a Get on all the files in the various projects from
    Visual Source Safe, then checkout the ones you need to compile. The program
    will then do the compiles, in the order listed in the *.DAT file, and if it
    can't find the version of the dependent VB files in the project needed (due
    to broken compatibility), it will get the new GUID and version number (using
    tlbinf32.dll), and try to compile the component again. Finally, after all
    the various projects are successfully compiled, it will check in all the
    files to VSS.

    "Due to the wide variation of ways that projects are set up, and the large
    number of source control systems (and how they are used), this code will not
    work unmodified with many projects. If you don't use VSS, for example, you
    must code a different method to do the checkout and checkin (even if it's
    batch processing from the command line). Even in these cases, the code
    should give you a good start on creating your own build automation. I was
    able to cut the time for a build from several hours down to 10 minutes at a
    company I worked for, and this was with 80+ VB components over 3 tiers. If
    you are doing multiple builds a week, this can be a real time saver."

    --
    L.J. Johnson, Slightly Tilted Software
    Microsoft MVP (Visual Basic)
    LJJohnson@SlightlyTiltedSoftware.com or LJJohnson@mvps.org
    <http://www.SlightlyTiltedSoftware.com>
    Ask the NT Pro at <http://www.devx.com/gethelp>





Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center