none
How to reduce dependencies in a VB project?

    Question

  • I have a two projects originally written in VB6, which I have upgraded to Visual Studio 2015 . When I created .msi installations for them (using VSI installer), I found that the more complex project has a reasonable list of .dll dependencies (DAO350, Interop.DAO and Microsoft.VisualBasic.PowerPacks) but the simpler project has a huge list, shown below.

    I assume that this project must contain references (system functions, form controls &c.) which were commonplace then, but which are not generally used now - so the old references probably just need to be replaced with new ones, to reduce the number of dependencies. I'm perfectly prepared to work through my project and replace these references with the up-to-date equivalents - but having looked through it, I cannot see what they are!  For instance, there don't seem to be any Imports in the code, or toolbox items on the forms, which don't also appear in the other project.

    Can someone please give me some suggestions as to what I need to look for, to reduce this dependency list?  (I have asked this question in the deployment forum, but they were not able to answer it, and see it as a VB question...)


    If it can't be done in Fortran 77 it's not worth doing, IMO

    Friday, March 10, 2017 10:15 AM

Answers

  • The first think you need in my perception to do is go to your Options: Tools -> Options -> Project and Solutions -> VB Defaults and set all options to On. (Option Compare I've set to Binary but that is your choice).

    Then look what errors you get. The most you get probably in the interop part.

    Because of Option Infer On, it can be less than without it. Option Infer On solves itself not set types at Design time. It is 100% type safe. As sample it makes in the code from dim x ="A String" in runtime dim x as string = "A String", what can it otherwise be. 

    With Option Strict Off, the types are set if it are objects at runtime. This is in fact the same as with VB6. With Option Strict On you have the chance your programs runs 10 times faster, but it runs as well more robust because not solved so called late binding can give errors. Therefore try to set it On. (It can be a lot of work to correct all errors given).

    The next step can be to remove the easiest reference to remove, which can be done in VB in many ways for instance using

    Project -> TheProject Properties -> References 

    I would begin with removing the axInterop to the Cdlg, maybe you like some very old ones, but those I see seldom anymore. The dialogs are a part currently of the namespace System.Forms but also in System.Window

    Then I would slowly remove all what is old starting after I got the experience with the dialogs with the OCX.

    Be aware that the replacing of DAO will be a hard way to go, if it is about MS-Access you should also direct think about SQL server, access does simply not run in 64 bit mode. 

    I think this is enough to start with


    Success
    Cor





    • Edited by Cor LigthertMVP Friday, March 10, 2017 10:41 AM
    • Marked as answer by Aylmer51 Friday, March 10, 2017 11:42 AM
    Friday, March 10, 2017 10:34 AM
  • You need to look at the Solution Explorer References in your application project, right click on a library (e.g. DAO), select Properties and then change the Embed Interop Types property to True. Changing it back to False will not embed the interop assembly.

    It sounds like you have removed most of the ActiveX/COM components so the corresponding interop assembly files can be deleted from your project.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    • Marked as answer by Aylmer51 Friday, March 10, 2017 5:02 PM
    Friday, March 10, 2017 4:49 PM

All replies

  • The first think you need in my perception to do is go to your Options: Tools -> Options -> Project and Solutions -> VB Defaults and set all options to On. (Option Compare I've set to Binary but that is your choice).

    Then look what errors you get. The most you get probably in the interop part.

    Because of Option Infer On, it can be less than without it. Option Infer On solves itself not set types at Design time. It is 100% type safe. As sample it makes in the code from dim x ="A String" in runtime dim x as string = "A String", what can it otherwise be. 

    With Option Strict Off, the types are set if it are objects at runtime. This is in fact the same as with VB6. With Option Strict On you have the chance your programs runs 10 times faster, but it runs as well more robust because not solved so called late binding can give errors. Therefore try to set it On. (It can be a lot of work to correct all errors given).

    The next step can be to remove the easiest reference to remove, which can be done in VB in many ways for instance using

    Project -> TheProject Properties -> References 

    I would begin with removing the axInterop to the Cdlg, maybe you like some very old ones, but those I see seldom anymore. The dialogs are a part currently of the namespace System.Forms but also in System.Window

    Then I would slowly remove all what is old starting after I got the experience with the dialogs with the OCX.

    Be aware that the replacing of DAO will be a hard way to go, if it is about MS-Access you should also direct think about SQL server, access does simply not run in 64 bit mode. 

    I think this is enough to start with


    Success
    Cor





    • Edited by Cor LigthertMVP Friday, March 10, 2017 10:41 AM
    • Marked as answer by Aylmer51 Friday, March 10, 2017 11:42 AM
    Friday, March 10, 2017 10:34 AM
  • Your answer was very useful, thank you!  I had already set Option Strict to 'on' in each block of code, so the first step didn't throw up any errors - but removing the Common dialog references raised 29 warnings, which were easily resolved (they mainly involved modal windows and measuring window sizes in twips).  There were also two entries for processing images, which gave no errors or warnings when I removed them, so I don't know why they were there.  And now, my two projects need exactly the same dependencies, which is all I wanted.  Thanks again.

    If it can't be done in Fortran 77 it's not worth doing, IMO


    • Edited by Aylmer51 Friday, March 10, 2017 1:50 PM
    Friday, March 10, 2017 11:42 AM
  • You might also want to look at merging the assemblies:

    https://www.microsoft.com/en-us/download/details.aspx?id=17630


    "One who has no vices also has no virtues..."

    Friday, March 10, 2017 1:45 PM
  • Interesting - but probably not worthwhile, in this case - the two assemblies are not always used together, and the total size of the remaining dependencies is about 750 KB, so there's not too much wastage of disk space.

    If it can't be done in Fortran 77 it's not worth doing, IMO

    Friday, March 10, 2017 1:57 PM
  • You are using a number of COM or ActiveX components which is why you have all of the COM Interop Assembly files. Those are created automatically when you add a COM/ActiveX component to your project. They are used for the COM interop bridge between unmanaged and managed code. You can eliminate deployment of these files by setting the Embed Interop Types option to True. I would test this thoroughly though because enabling this option can produce some side affects.

    DAO350.dll is typically a Windows system file (Access Jet Database Engine) so it would not be deployed.

    I do not know anything about the Microsoft Repository Engine files (CDLG). This looks like an older (Windows Server?) technology and I don't know if there are any .NET libraries to replace it.

    I don't know of any direct replacement for the Windows Image Acquisition library (wiaaut.dll) so you are probably stuck with that one until the code is rewritten.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Friday, March 10, 2017 2:38 PM
  • Thank you.  Fortunately, wiaaut.dll disappeared when I removed the image acquisition items, which the project did not seem to need.  CDLG used to be known as 'Common Dialog' in VB6, and was (I think) the source of a number of window tools, such as the pull-down menu at the top of a form.  All of these tools have been replaced, I think, but it is tedious to re-write everything using the new ones.

    I've now set Embed Interop Types to true on one project (which cause the dependency to disappear from the list), and will start some testing.

    But on a second project, when I select the dependency's properties, the Embed Interop Types option isn't there!  (see below) - what am I doing wrong?

    And - if embedding it DOES cause problems, how do I de-embed it?


    If it can't be done in Fortran 77 it's not worth doing, IMO




    • Edited by Aylmer51 Friday, March 10, 2017 4:35 PM
    Friday, March 10, 2017 3:38 PM
  • You need to look at the Solution Explorer References in your application project, right click on a library (e.g. DAO), select Properties and then change the Embed Interop Types property to True. Changing it back to False will not embed the interop assembly.

    It sounds like you have removed most of the ActiveX/COM components so the corresponding interop assembly files can be deleted from your project.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    • Marked as answer by Aylmer51 Friday, March 10, 2017 5:02 PM
    Friday, March 10, 2017 4:49 PM
  • Ah....  yes.  Thank you so much - I'm now down to just one dependency, Microsoft.VisualBasic.PowerPacks, so everything looks much neater.  I think I'll leave it at that!

    If it can't be done in Fortran 77 it's not worth doing, IMO

    Friday, March 10, 2017 5:01 PM