Hello Waldyn,

Thanks for posting.

As far as I know, the setup project will mark the excluded files as
"Exclude = true" in the "vdproj" file. If I copy the whole project to
another machine, these marks will be carried on as well.

I have also tried to reproduce your situation using Visual SourceSafe but
failed, here are my steps:

1. Create a Class Library project, a Windows Application project and a
Setup project.

2. In the Windows Application project, I add reference to the Class Library
project.

3. Add the primary output of the Windows Application project to the Setup
project.

4. Mark the dependency of the Class Library as "Exclude".

5. Put the solution under Visual SourceSafe control.

6. Open VS.Net on another machine and use "File" | "Source Control" | "Open
From Source Control..."

7. Open the solution. At this time, the "Detected Dependencies" will not
have the Class Library listed.

8. I build the Setup project (with "Check-in" state). This time the Class
Library appears under the "Detected Dependencies". It's status is still
"Exclude".

9. I check out the solution and rebuild the Setup project. The dependency
on the Class Library is still "Exclude".

I am using Visual Studio .Net 2003 and Visual SourceSafe 6.0a.

To further isolate the issue, I suggest that you manually copy the solution
to the other machine. Normally, the dependency should remain "Exclude". If
the copying works as expected, then the problem is likely related to VSS,
instead of VS.Net. I hope this makes sense to you.

Regards,

Felix Wang
Microsoft Online Partner Support

I have a similar problem:

I've got a large .NET application that is segmented into multiple packages.
Our build architecture can be summaraized like this:

1) Each package is contained in a single solution.
2) Each solution results in the creation of a merge module that encapsulates
the deployment requirements of that package (including merge module
references to other package's).
3) The installer is an MSI project that aggregates all of the package merge
modules, contains any necessary launch conditions and puts the user
interface on the install procedure.

So to the build the app, we just need to build each solution in order of
least dependent to most dependent, and then build the MSI project.

It all works great (in fact better than most build procedures I have seen)
except for one pernicious problem: VS.NET's deployment project detected
dependencies don't always seem to stick.

I've read some of the suggestions from this and other windows installer
related newsgroups and followed the suggestions I've seen: I exclude
dependencies I don't want; when adding a Primary Project Output to an MSM
deployment project I use the release configuration explicitly rather than
the "Active" configuration (we don't build debug installers).

Three things I've notice:
1) If you set the SearchPath property of the merge module project to the
location where all of the application's merge modules get built it will
automagically add the correct merge module reference for you (that's pretty
cool).

2) For two projects where project A depends on project B, deploy project
includes the out put of project B as a dependency of Project A, even the out
Primary Output of Project B is included in the deployment project. It should
be smart enough to detect that both the dependency and the project output
are the asame image, and not force me to mnually exclude the detected
dependency.

3) As part of our build process, we increment the AssemblyVersion revision
number with each build on the build machine. When a developer installs the
nightly build and opens a package's solution, detected dependencies that
have been manually excluded in the past, are now included (presumably
because the AssemblyVersion number changed). This means we need to remember
to keep excluding the assemblies and if this step is forgotten the install
goes awry.

Is there any way to get better control over detected dependencies?

Any help is greatly appreciated!

don