Search

An error occurred while validating. HRESULT = '80004005' by megabitee

Closed
as Fixed Help for as Fixed

10
1
Sign in
to vote
Type: Bug
ID: 434666
Opened: 4/23/2009 6:01:22 AM
Access Restriction: Public
0
Workaround(s)
4
User(s) can reproduce this bug
We are planning a series of 4 applications with increasing capabilities built on shared projects. The applications will be configured in such a way that the lesser versions will disable capabilities of the more advanced versions by hiding user interface elements.

We attempted to do this in two solutions by creating a solution specific project that had the same name, Project Guid, and Assembly Guid in each solution.

solution1
projectA1 specifies this is application1
projectB
projectC references projectA
projectD
etc.
Solution1Setup

solution2
projectA2 specifies this is application2
projectB
projectC references projectA
projectD
etc.
Solution2Setup

This actually works fine when building the solutions from the IDE.

But, there is some kind of dependency computation problem when trying to create Setups for each solution.

Looking at "Primary Output for ProjectC" from the Solution2Setup File View there were (None). When we looked at the Project Dependencies... for ProjectC from Solution Explorer in solution2 there were several. In addition, when we looked at the dependencies for ProjectC from the Solution1Setup File View it showed the correct dependencies.
If we remove and replace the reference to ProjectA in solution2, Solution2Setup builds without error but then Solution1Setup is broken in the same way.
Details (expand)
Product Language
English

Version

Visual Studio 2008 SP1
Operating System
Windows XP Professional
Operating System Language
English
Steps to Reproduce
1) create solution1
2) create projectA1 in a subdirectory under solution1. set the project output to "..\..\Assemblies"
3) create projectC in a directory on the same level as solution1. set the project output to "..\Assemblies"
4) from projectC, add a reference to projectA1

5) create solution2
6) copy projectA1 directory under solution2, this is now projectA2
7) add existing projectA2
8) add existing projectC

You can now build solution1 or solution2, both will build to the Assemblies directory. Notice that projectA1 and projectA2 have the same name, project Guid, and Assembly Guid. This is necessary to maintain the reference in projectC. projectA1 and projectA2 will build only for their respective solution and can contain whatever unique behavior is desired.

9) create setup project Setup1 in a subdirectory under solution1
10) add "Primary output from" projectA1 and projectC
11) clean and build solution1
12) build Setup1, "Successful"

13) create setup project Setup2 in a subdirectory under solution2
14) add "Primary output from" projectA2 and projectC
15) clean and build solution2
16) build Setup2, "An error occurred while validating. HRESULT='80004005'"

I created this sample as I was typing. I received the error as described.
Actual Results
An error occurred while validating. HRESULT = '80004005'
Expected Results
no error
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
File Name Submitted By Submitted On File Size  
VS.zip (restricted) 4/23/2009 -
Sign in to post a comment.
Posted by Rui Rasteiro on 12/4/2009 at 11:54 AM
I've also had this error.. the cause:

http://tutorialgenius.blogspot.com/2008/10/installer-compile-error-occurred-while.html

"The issue is based around project dependencies. When you add a project output to an installer, you'll notice the installer automatically retrieves its dependencies (External DLLs, project references etc.). There may be a time when you remove a project from the solution, or re-locate them, by which, they can no longer be found or referenced in this case."

Just removes all the references and re-added them to them problematic project.
Posted by Microsoft on 6/16/2009 at 4:46 PM
You're correct that the workaround does seem to break the other solution's Setup. We've looked closer into the issue and here are two potential solutions depending on the situation:

Option 1: If the two class libraries are idential, move "ClassLibrary" to a general location (since the windows forms application in the general location depends on it).

Option 2: If the two class libraries are different, split the "Windows Forms Application" project into two (one copy for each solution), so that each of the two versions of the windows forms application can depend on the correct Class Library.

The solutions to both option 1 and 2 are attached with file names prefixed with "VS_Move".

I hope that helps.
Posted by megabitee on 5/14/2009 at 6:23 AM
I think you do not understand. The problem is not caused by a cross-solution project reference. All references are to projects within each solution. Solution1 references ClassLibrary1 from Solution1\ClassLibrary1. Solution2 correctly references ClassLibrary1 from Solution2\ClassLibrary1. Both solutions compile, link, and run.

The problem is that setup projects appear to maintain a cross-solution reference. When a reference is added in a solution, it appears that setup projects record an internal solution specific reference. When the setup is built in the other solution, it throws an error because it still has some reference to the other solution. Setup projects are somehow bound to one solution.

The workaround does not work. I* do not understand how this will make both setup projects build wihtout error. When I re-add the reference in Solution2, and save the solution, then the setup in Solution1 is broken. If I then fix Solution1, the setup in Solution2 is broken.

Perhaps you could modify my attachment then send it back to me so that I can understand what you are trying to say.
Posted by Microsoft on 5/13/2009 at 2:25 PM
Hi,

Thank you for reporting this issue. We were able to reproduce the problem and have identified the root cause. The problem is caused by cross-solution project reference between Solution1 and Solution2. From the attached project, the project “WindowsFormApplication1” in Solution2 references a project that is not in Solution2 (it references ClassLibrary1 from Solution1). To fix the error, the workaround is to copy the ClassLibrary1 project to Solution2 and re-add the reference to ClassLibrary1 within its own solution.

Project-to-project references only works within the same solution. If you have to split into two solutions and split the code for your class library into two projects, you need to also split the project that references the class library into two projects (one for each solution) in order to avoid project references outside the current solution.

I hope this helps.

Candy Chiang
Program Manager – Visual Studio
Posted by Microsoft on 4/27/2009 at 4:24 PM
Thank you for reporting this issue. We're looking into this and will get back to you with more updates.

Visual Studio Product Team
Posted by Microsoft on 4/23/2009 at 8:21 PM
Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team
Posted by megabitee on 4/23/2009 at 9:54 AM
this may be a related problem
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434732
Sign in to post a workaround.