locked
Detected dependencies reappears

    Question

  • I created an setup project which includes about 10 project outputs. When I add the primary output of these 10 projects, the setup project automatically detects the dependencies and include them under the file system and 'detected dependencies'. I removed all of them since they are all third party components, but when I reopen the solution or open the solution in new workspace, these detected dependencies are automatically added again and some of them are even duplicated. This happends even the setup project is not check out which means to get rid of them all, I have to check out, exclude them and check in again.

    If anyone has similar problem, please let me know or guide me to a thread if there is any.

    - Gerry
    Thursday, October 04, 2007 11:12 PM

Answers

  •  Gerry S. A. wrote:
    First of all, I noticed that I cannot manually remove the detected dependencies since they are automatically generated by the reference. So as you said, I do use exclude.

     

    Oops, sorry.  I had wondered how you were 'removing' the dependencies - I should have realised you meant exclude.

     

    My problem is that the dependencies that I already have excluded does not stay excluded.

     

    That's odd.

     

    For example, say I created a setup project, added primary outputs, set all settings, and excluded all dependencies. I check in the project and everything is great. Now I close Visual Studio and reopen the same solution. All the detected dependencies that I excluded should remain excluded since there wasn't any change in the solution nor the projects. This issue makes me to check out the setup project again and exclude all the dependencies again and check it in.

     

    That's really odd.  I don't think that just closing and re-opening a solution should cause any change at all. 

     

    The setup project's vdproj file is a text file containing XML so you can read the contents of the project file with notepad or Visual Studio's "Compare Versions" tool or even SourceSafe explorer's own 'editor'. 

     

    If you run SourceSafe Explorer (or TFS) and view the stored copy of the setup.vdproj file as a text file, are the problem dependencies marked as excluded or not?   For example, on a quick test project I put together using the Microsoft.Office.Tools.Common.Dll assembly as a dependency, the setup entry for the assembly looks like this...

     

    Code Block

     "{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_5FA962108932B823D08F70FB400ADFE7"
     {
     "AssemblyRegister" = "3:1"
     "AssemblyIsInGAC" = "11:FALSE"
     "AssemblyAsmDisplayName" = "8:Microsoft.Office.Tools.Common, Version=8.0.0.0,
        Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
    processorArchitecture=MSIL"
         "ScatterAssemblies"
                     {
             "_5FA962108932B823D08F70FB400ADFE7"
                         {
             "Name" = "8:Microsoft.Office.Tools.Common.dll"
             "Attributes" = "3:512"
                         }
                     }
     "SourcePath" = "8:Microsoft.Office.Tools.Common.dll"
     "TargetName" = "8:"
     "Tag" = "8:"
     "Folder" = "8:_87AAF36D795840F8BC8C711D99F54F42"
     "Condition" = "8:"
     "Transitive" = "11:FALSE"
     "Vital" = "11:TRUE"
     "ReadOnly" = "11:FALSE"
     "Hidden" = "11:FALSE"
     "System" = "11:FALSE"
     "Permanent" = "11:FALSE"
     "SharedLegacy" = "11:FALSE"
     "PackageAs" = "3:1"
     "Register" = "3:1"
     "Exclude" = "11:TRUE"
     "IsDependency" = "11:TRUE"
     "IsolateTo" = "8:"
    }

     

     

    Note the third property from the bottom - 'Exclude'.  In your checked-in version of the vdproj file, is the property set to FALSE or TRUE? 

     

    After you close and open the solution, and the dependencies are all not-excluded again, you must have to check out the vdproj file before the exclude command will work.  Once you've checked the setup project out of SCC and have marked the dependencies as excluded once more, use the "View | Pending Checkins" menu to examine the differences between your checked out copy of the vdproj file and the SCC version of that same file.  Are the two files the same or different?  In particular, is the "Exclude" property value different bewteen the two copies of the file?  Is the Exclude property set to true in the local copy?  Are there any other differences between the two copies of the file?

     

    Finally, if you check-in the changes you have made, does the SCC version of the vdproj file now reflect the Exclude values you just checked in?  If you close and open the solution again (so the dependencies re-appear) then close the solution and open the vdproj file with Notepad (or your favourite XML editor), is Exclude set to True or False?

     

    I just think this is very redundant procedure that is not necessary

     

    I agree it is way more work than you should need to do.

    Friday, October 05, 2007 9:49 PM
  • I am having this problem too.  It seems to only happen when there are two identical dependancies.  When I look at the .vdproj file, the "Exclude" property for the dependancies is TRUE, but when I look at it in the IDE, it doesn't have a red circle and line through it and when built it gives warnings about duplicate files going to the same location.

     

    Here is an example of this from my vdproj file.  The dll ManagedI18N_mu2yd.dll is detected twice as a dependancy (and shows up twice under the "Detected Dependencies" node.  In the IDE, it looks like these two nodes are NOT excluded (ie they do not have the red circle and line through them), and they generate warnings in the build.

     

    Code Block

    ...

                "{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_8EE0B35BFE30455B15EC566BB507E4FA"
                {
                "AssemblyRegister" = "3:1"
                "AssemblyIsInGAC" = "11:FALSE"
                "AssemblyAsmDisplayName" = "8:ManagedI18N_mu2yd, Version=1.0.2838.30084, Culture=neutral, processorArchitecture=x86"
                    "ScatterAssemblies"
                    {
                        "_8EE0B35BFE30455B15EC566BB507E4FA"
                        {
                        "Name" = "8:ManagedI18N_mu2yd.dll"
                        "Attributes" = "3:512"
                        }
                    }
                "SourcePath" = "8:ManagedI18N_mu2yd.dll"
                "TargetName" = "8:"
                "Tag" = "8:"
                "Folder" = "8:_E32F875FED284B95A3EDD2EB09E871A6"
                "Condition" = "8:"
                "Transitive" = "11:FALSE"
                "Vital" = "11:TRUE"
                "ReadOnly" = "11:FALSE"
                "Hidden" = "11:FALSE"
                "System" = "11:FALSE"
                "Permanent" = "11:FALSE"
                "SharedLegacy" = "11:FALSE"
                "PackageAs" = "3:1"
                "Register" = "3:1"
                "Exclude" = "11:TRUE"
                "IsDependency" = "11:TRUE"
                "IsolateTo" = "8:"
                }

    ...

                "{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_F43EBA8F1439ECF6550AE1514271A20A"
                {
                "AssemblyRegister" = "3:1"
                "AssemblyIsInGAC" = "11:FALSE"
                "AssemblyAsmDisplayName" = "8:ManagedI18N_mu2yd, Version=1.0.2838.30084, Culture=neutral, processorArchitecture=x86"
                    "ScatterAssemblies"
                    {
                        "_F43EBA8F1439ECF6550AE1514271A20A"
                        {
                        "Name" = "8:ManagedI18N_mu2yd.dll"
                        "Attributes" = "3:512"
                        }
                    }
                "SourcePath" = "8:ManagedI18N_mu2yd.dll"
                "TargetName" = "8:"
                "Tag" = "8:"
                "Folder" = "8:_E32F875FED284B95A3EDD2EB09E871A6"
                "Condition" = "8:"
                "Transitive" = "11:FALSE"
                "Vital" = "11:TRUE"
                "ReadOnly" = "11:FALSE"
                "Hidden" = "11:FALSE"
                "System" = "11:FALSE"
                "Permanent" = "11:FALSE"
                "SharedLegacy" = "11:FALSE"
                "PackageAs" = "3:1"
                "Register" = "3:1"
                "Exclude" = "11:TRUE"
                "IsDependency" = "11:TRUE"
                "IsolateTo" = "8:"
                }

     

     

     

    I can right click on them in the IDE and select "Exclude" and they then appear excluded and all is well.  When I look in the vdproj file at this stage, it has shuffled around a few blocks and re-assigned some of those long hex numbers.

     

    Then when I restart the IDE, I am back at the original problem.

     

    I am using Visual Studio 2005 with SP1

    Wednesday, October 10, 2007 4:36 AM

All replies

  • The setup project has to refresh the dependencies list when you rebuild you solution (or part of your solution) because any change you make to one of your 10 projects might introduce a new dependency or do away with a previously detected dependency.  That's probably why the dependencies showed up again after you had removed them.

     

    Rarther than remove the detected dependencies, you should mark each one by setting the Exclude property to true.  One way to do that is to right click on the entry under "Detected Dependencies" and click on the Exclude menu item.  Marking a dependency as excluded tells the setup program that you know about the dependency but don't want the file included in the installer or merge module that is being  built. 

     

    When the setup project refreshes the detected dependencies list, you'll still need to exclude any new dependencies that are discovered but the ones you've already excluded should stay excluded.

    Thursday, October 04, 2007 11:50 PM
  • Thanks for posting reply. I should make this sounds clearer.

    First of all, I noticed that I cannot manually remove the detected dependencies since they are automatically generated by the reference. So as you said, I do use exclude.

    I understand that the setup project refreshs the dependencies list, so when a new dependency is discovered, it will populate the list. My problem is that the dependencies that I already have excluded does not stay excluded. For example, say I created a setup project, added primary outputs, set all settings, and excluded all dependencies. I check in the project and everything is great. Now I close Visual Studio and reopen the same solution. All the detected dependencies that I excluded should remain excluded since there wasn't any change in the solution nor the projects. This issue makes me to check out the setup project again and exclude all the dependencies again and check it in.

    I just think this is very redundant procedure that is not necessary. Let me know if something I am missing here. Thanks.
    Friday, October 05, 2007 7:52 PM
  •  Gerry S. A. wrote:
    First of all, I noticed that I cannot manually remove the detected dependencies since they are automatically generated by the reference. So as you said, I do use exclude.

     

    Oops, sorry.  I had wondered how you were 'removing' the dependencies - I should have realised you meant exclude.

     

    My problem is that the dependencies that I already have excluded does not stay excluded.

     

    That's odd.

     

    For example, say I created a setup project, added primary outputs, set all settings, and excluded all dependencies. I check in the project and everything is great. Now I close Visual Studio and reopen the same solution. All the detected dependencies that I excluded should remain excluded since there wasn't any change in the solution nor the projects. This issue makes me to check out the setup project again and exclude all the dependencies again and check it in.

     

    That's really odd.  I don't think that just closing and re-opening a solution should cause any change at all. 

     

    The setup project's vdproj file is a text file containing XML so you can read the contents of the project file with notepad or Visual Studio's "Compare Versions" tool or even SourceSafe explorer's own 'editor'. 

     

    If you run SourceSafe Explorer (or TFS) and view the stored copy of the setup.vdproj file as a text file, are the problem dependencies marked as excluded or not?   For example, on a quick test project I put together using the Microsoft.Office.Tools.Common.Dll assembly as a dependency, the setup entry for the assembly looks like this...

     

    Code Block

     "{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_5FA962108932B823D08F70FB400ADFE7"
     {
     "AssemblyRegister" = "3:1"
     "AssemblyIsInGAC" = "11:FALSE"
     "AssemblyAsmDisplayName" = "8:Microsoft.Office.Tools.Common, Version=8.0.0.0,
        Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
    processorArchitecture=MSIL"
         "ScatterAssemblies"
                     {
             "_5FA962108932B823D08F70FB400ADFE7"
                         {
             "Name" = "8:Microsoft.Office.Tools.Common.dll"
             "Attributes" = "3:512"
                         }
                     }
     "SourcePath" = "8:Microsoft.Office.Tools.Common.dll"
     "TargetName" = "8:"
     "Tag" = "8:"
     "Folder" = "8:_87AAF36D795840F8BC8C711D99F54F42"
     "Condition" = "8:"
     "Transitive" = "11:FALSE"
     "Vital" = "11:TRUE"
     "ReadOnly" = "11:FALSE"
     "Hidden" = "11:FALSE"
     "System" = "11:FALSE"
     "Permanent" = "11:FALSE"
     "SharedLegacy" = "11:FALSE"
     "PackageAs" = "3:1"
     "Register" = "3:1"
     "Exclude" = "11:TRUE"
     "IsDependency" = "11:TRUE"
     "IsolateTo" = "8:"
    }

     

     

    Note the third property from the bottom - 'Exclude'.  In your checked-in version of the vdproj file, is the property set to FALSE or TRUE? 

     

    After you close and open the solution, and the dependencies are all not-excluded again, you must have to check out the vdproj file before the exclude command will work.  Once you've checked the setup project out of SCC and have marked the dependencies as excluded once more, use the "View | Pending Checkins" menu to examine the differences between your checked out copy of the vdproj file and the SCC version of that same file.  Are the two files the same or different?  In particular, is the "Exclude" property value different bewteen the two copies of the file?  Is the Exclude property set to true in the local copy?  Are there any other differences between the two copies of the file?

     

    Finally, if you check-in the changes you have made, does the SCC version of the vdproj file now reflect the Exclude values you just checked in?  If you close and open the solution again (so the dependencies re-appear) then close the solution and open the vdproj file with Notepad (or your favourite XML editor), is Exclude set to True or False?

     

    I just think this is very redundant procedure that is not necessary

     

    I agree it is way more work than you should need to do.

    Friday, October 05, 2007 9:49 PM
  • I am having this problem too.  It seems to only happen when there are two identical dependancies.  When I look at the .vdproj file, the "Exclude" property for the dependancies is TRUE, but when I look at it in the IDE, it doesn't have a red circle and line through it and when built it gives warnings about duplicate files going to the same location.

     

    Here is an example of this from my vdproj file.  The dll ManagedI18N_mu2yd.dll is detected twice as a dependancy (and shows up twice under the "Detected Dependencies" node.  In the IDE, it looks like these two nodes are NOT excluded (ie they do not have the red circle and line through them), and they generate warnings in the build.

     

    Code Block

    ...

                "{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_8EE0B35BFE30455B15EC566BB507E4FA"
                {
                "AssemblyRegister" = "3:1"
                "AssemblyIsInGAC" = "11:FALSE"
                "AssemblyAsmDisplayName" = "8:ManagedI18N_mu2yd, Version=1.0.2838.30084, Culture=neutral, processorArchitecture=x86"
                    "ScatterAssemblies"
                    {
                        "_8EE0B35BFE30455B15EC566BB507E4FA"
                        {
                        "Name" = "8:ManagedI18N_mu2yd.dll"
                        "Attributes" = "3:512"
                        }
                    }
                "SourcePath" = "8:ManagedI18N_mu2yd.dll"
                "TargetName" = "8:"
                "Tag" = "8:"
                "Folder" = "8:_E32F875FED284B95A3EDD2EB09E871A6"
                "Condition" = "8:"
                "Transitive" = "11:FALSE"
                "Vital" = "11:TRUE"
                "ReadOnly" = "11:FALSE"
                "Hidden" = "11:FALSE"
                "System" = "11:FALSE"
                "Permanent" = "11:FALSE"
                "SharedLegacy" = "11:FALSE"
                "PackageAs" = "3:1"
                "Register" = "3:1"
                "Exclude" = "11:TRUE"
                "IsDependency" = "11:TRUE"
                "IsolateTo" = "8:"
                }

    ...

                "{9F6F8455-1EF1-4B85-886A-4223BCC8E7F7}:_F43EBA8F1439ECF6550AE1514271A20A"
                {
                "AssemblyRegister" = "3:1"
                "AssemblyIsInGAC" = "11:FALSE"
                "AssemblyAsmDisplayName" = "8:ManagedI18N_mu2yd, Version=1.0.2838.30084, Culture=neutral, processorArchitecture=x86"
                    "ScatterAssemblies"
                    {
                        "_F43EBA8F1439ECF6550AE1514271A20A"
                        {
                        "Name" = "8:ManagedI18N_mu2yd.dll"
                        "Attributes" = "3:512"
                        }
                    }
                "SourcePath" = "8:ManagedI18N_mu2yd.dll"
                "TargetName" = "8:"
                "Tag" = "8:"
                "Folder" = "8:_E32F875FED284B95A3EDD2EB09E871A6"
                "Condition" = "8:"
                "Transitive" = "11:FALSE"
                "Vital" = "11:TRUE"
                "ReadOnly" = "11:FALSE"
                "Hidden" = "11:FALSE"
                "System" = "11:FALSE"
                "Permanent" = "11:FALSE"
                "SharedLegacy" = "11:FALSE"
                "PackageAs" = "3:1"
                "Register" = "3:1"
                "Exclude" = "11:TRUE"
                "IsDependency" = "11:TRUE"
                "IsolateTo" = "8:"
                }

     

     

     

    I can right click on them in the IDE and select "Exclude" and they then appear excluded and all is well.  When I look in the vdproj file at this stage, it has shuffled around a few blocks and re-assigned some of those long hex numbers.

     

    Then when I restart the IDE, I am back at the original problem.

     

    I am using Visual Studio 2005 with SP1

    Wednesday, October 10, 2007 4:36 AM
  • Well,

    I do have the same issue here. We have many assemblies that depend on common assemblies. We also have plugin assemblies that also depends on the common assemblies but that go into a diffrent directory (under a plugin subdirectory) We do not want the common assemblies to be in the same directory as their plugin, as well as in the application directory. We only want them in the application directory.

    Excluding them will always revert to "not excluded" after the next reload of the solution. That is quite annoying, because it makes the build process of the setups anything but trivial.

    Is there any work-around? Has this been aknowledged as an issue?

    Thanks,

    Vincent

    • Proposed as answer by redtracy Sunday, August 31, 2008 9:04 PM
    Monday, July 28, 2008 7:32 PM
  • I have been able to reproduce this problem using the following ingredients:
    1. MyDLL.dll - externally built C# assembly
    2. ClassLib1 - C# assembly references MyDLL.dll
    3. ClassLib2 - C# assembly that references ClassLib1
    3. ClassLib3 - C++/CLI assembly that references ClassLib1
    4. Add ClassLib1, ClassLib2, and ClassLib3 to a Setup & Deployment project

    Every time you open the solution, MyDLL.dll is back to not excluded.  And there are two copies of it.

    The workaround I found was to add a reference to MyDLL.dll in both ClassLib2 and ClassLib3 (even though they don't really need it).  This somehow changes things to that MyDLL.dll will stay excluded.

    • Proposed as answer by redtracy Sunday, August 31, 2008 9:05 PM
    Friday, August 29, 2008 7:36 PM
  • Diddo on the problem.  Also I have the outputs of two projects (a Service and a Gui version of the same program) included, and some of their shared dependencies appear twice.  I exclude one copy of them, as discussed in this thread they return to included.

    Any information would be appreciated.
    Monday, December 08, 2008 2:44 PM
  • I have this problem also:

    For my VS2008 Setup project I have some duplicate detected dependencies (have 17 projects in my solution):

    <file name 1>.dll
    <file name 1>.dll
    <file name 2>.dll
    <file name 2>.dll

    So I right click -> Select Exclude on the 2nd <file name 1>.dll & <file name 2>.dll

    A red exclude icon appears as expected.

    However, after each rebuild (F6) the icons are lost again!

    As a side-note: the exclude icons remain for non-duplicate .DLLs

    Any ideas how I can stop the exclude icons from dissapearing every time I rebuild the solution?


    Monday, June 01, 2009 3:39 PM
  • I wonder if completely removing any Primary Outputs from your setup project and then replacing them with hardcoded paths to the outputs would fix this problem.
    ...Joe
    Wednesday, July 15, 2009 1:33 PM
  • Hey, I'm having the exact same issue. Another odd thing is that some dependencies in fact DO REMEMBER that they were previously marked as excluded. So after I re-launch Visual Studio, I end up having some dependencies remaining excluded and some revived again and residing in their original locations under the File System tab.

    Also, dependencies that re-appear again and again, do not remember such properties as [Condition], [Permanent], and [Vital]. Maybe some other properties are also not persisted, but I just didn't experiment with those.

    Anyone has been able to find a workaround?
    Wednesday, September 16, 2009 1:39 PM
  • Thanks to redtracy and another post that I can't seem to find again, I was able to eliminate the 2 duplicates I had. One of the duplicated DLLs was referenced by just about everything, so I set CopyLocal to False in its reference in all non-application projects and that eliminated its duplication.  My other duplicate is referenced by that DLL. Making that same change to its reference eliminates the duplicate dependencies, but also caused the DLL to not be included in the applications' bin folders. Adding a specific (though inappropriate) reference to that bottom-level project in the application projects (as redtracy suggested) eliminated that problem.
    • Proposed as answer by John Whitmire Wednesday, November 18, 2009 5:14 PM
    Wednesday, November 18, 2009 5:14 PM
  • I have this problem also and it's making me go nuts.  I believe that part of my problem is that I am often switching between debug and release build.  This causes the setup project to throw out the old dependencies and add in new ones.  I guess I should say that my build system and compile system references debug versions of all libraries for debug builds and release versions for release builds. so I guess the dependencies really are different.  I wish that the setup project would just key on the short name for the library, or that we could exclude dependencies on project output includes or that the dependencies would show up in the outputs list so we could exclude them explicitly.  sigh.  I have alway felt that the setup project implementation was one of Microsoft's more amateurish products.
    • Edited by msauper Monday, September 12, 2011 4:48 PM moderate superlative.
    Monday, September 12, 2011 3:55 PM