locked
dll problem. RRS feed

  • Question

  • How do we ensure that a DLL in a solution is updated when a referenced solution is compiled?

     

     

    We are currently in the process of migrating our software package from RPG code into AVR.net. Currently, we are running our application on an AS/400. Within our existing code and from within any program running on the AS/400, there are external program calls which will simply call another RPG program.  

     

    In particular, we have one program (inquiry program) which can be called from any screen within the system. On the AS400, the inquiry program is independent and a code change to this program would not require any changes to programs that call it. However in .Net this situation is a little different. In order to call the inquiry program from another solution, we must add a reference to the inquiry. This will create an inquiry DLL in the calling program’s bin folder (copy local is set to true). If we make a change to the inquiry program, a new DLL is created and we need to ensure that the DLL in every program’s bin folder is updated and contains the latest version.

     

     

    Here is a small illustration of our circular reference problem:

     

    Our inquiry system can be called from any screen within our application by pressing a button. This button is available on every screen. As soon as the inquiry system is called, it is passed some codes to a traffic director program and then the traffic director program determines which program/project to call. Then after calling the first program, for example, part inquiry, you can call another program/project by passing another code, but it always returns to the traffic director to determine which program/project to call. We could structure our project to encompass all pgms within the inquiry, but then we would have a big build. To make matters worse, we have another button within each inquiry which will call another program in maintenance mode.

     

     

     

    Part Inquiry

    Inquiry System

    Traffic Director

     


    W/O Inquiry

    Main Menu

     

     

                                                                        

     

     

     

     

     

     

     

     

     

     

     

     

     

    We are not availing of any “build” software, that is why we started sharing our dll’s, to ensure that each project received the latest version of the dll.

     

    What is the common practice for ensuring that a DLL in a solution is updated when a referenced solution is compiled? We have searched the web and while everyone seems to have the same question, no one seems to have a valid answer.

    Wednesday, June 21, 2006 5:13 PM

All replies

  • It kind of depends on your deployment scenario.

    If the projects that reference your DLL will typically be deployed at the same time, you could simply add a project reference instead of a straight DLL reference. This means adding the referenced project to your solution. When you do a built make sure you have the latest copy of the source code and the DLL will be up-to-date automatically.

    It is likely, however, that this is not your deployment scenario.

    Another option would be to place all DLLs in a central location (such as a shared drive). Make sure you reference that DLL in the shared location (and set copy local to true). VS.NET will detect that the DLL has been modified and will copy the latest version as part of the built process.

    You could also put your DLL in the Global Assembly Cache and use binding policies to force your application to always reference the latest version of the assembly. Since all your application will reference the DLL in the Global Assembly Cache, regardless of their particular locations on the machine, they will always reference the latest copy as long as the copy in the GAC remains up to date. Using the GAC makes development somewhat more complicated and it's usually not a best practice until after your projects have stabilized and you can do planned builds / deployments.
    Wednesday, June 21, 2006 9:19 PM