Home Dashboard Directory Help
Search

ERROR: Unable to build project output group 'Content Files from <ProjectName> (Active)' by Pedro G. Dias


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


1
0
Sign in
to vote
Type: Bug
ID: 538943
Opened: 3/4/2010 3:40:32 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

PS: I cannot find any VS2008 version to peg this under, the drop-down only lists VS2010.
The problem is in Setup from VS2008. I have not tried the same in VS2010

The problem:
I am unable to build a Setup Project for an Asp.Net project, the installer itself fails with the message:
"ERROR: Unable to build project output group 'Content Files from <Project Name> (Active)'"

Normally, this error is easilly fixed by simply adding or removing references that are marked with a yellow triangle (indicating that they are missing), but this time, I cannot find any of these.

To make matters worse, when I right-click the setup project in VS2008 and select "ReBuild", it works every second time with no errors, and every second time with the error above. I've ran the build using detailed output to no avail, no hints are given.

So, I did a dir /S /B on the entire solution to see if there is a change on disk from when the setup project builds and when it does not and I found that there are some mysterious xml files that are in the bin folder every other build, these come from libraries such as Log4Net.dll (gives log4net.xml), Castle.Windsor.dll (gives Castle.Windsor.xml) etc. I suspect that these dlls have embedded these xml files as content files, because they contain, in general what appears to be intellisense text.

I've ensured that none of the projects are configured to render any xml documentation.

What I *suspect* is that these xml files are embedded as Content, and that for some reason, because they are in referenced dlls and not directly referenced dlls, they are extracted too late for the setup project to catch them. What I can't explain is why this works every second rebuild. Running the devenv.exe as a command line to build the same setup project fails every time.


Other things that I've done:
I run VS2008 as administrator.
I have reviewed the ASP.Net Project numerous times, using "show all files" to see if any reference is missing, but found none.
I've tried to exclude the dlls that contain the xml files from the "Content Files" in teh setup project as well as using filters such as *.xml etc.

I hope that someone at the Setup team knows what this is about and can help me, I am completely stuck, and cannot get our CI server to build this last setup project because of it, it is a major blocker.
Details
Sign in to post a comment.
Posted by Rahul Dedhia on 9/14/2012 at 5:03 AM
u can remove an yellow marked triangle file. and then try to create it again
Posted by Hai Don on 6/3/2010 at 9:01 PM
I believe it is an issue when user try to build the setup project for web application on visual studio 2010. I have some experience on that when I try to build one project which is upgraded from a legacy ASP.net web application. The application was created with VS2005 as web application template instead of web site. It is fine to build setup project with the help of webdeploy template on VS2008, but you can not make it compiled with default setting on VS 2010. When you are working on the setup project in VS2010, the recommend items should be included are primary output and content files. Just as Pedro mentioned, you need to exclude those project out file, especially those dll in the bin folder first. Otherwise you will encounter the same issue as we did before.
Posted by Microsoft on 3/30/2010 at 10:59 AM
Hi,

It has been a week and we haven't heard from you. We are going to close this issue now as we cannot reproduce the problem. If the problem persists, please feel free to log a new bug and we will be happy to take a look.

Thank you.
Posted by Microsoft on 3/30/2010 at 10:59 AM
Hi,

It has been a week and we haven't heard from you. We are going to close this issue now as we cannot reproduce the problem. If the problem persists, please feel free to log a new bug and we will be happy to take a look.

Thank you.
Posted by Microsoft on 3/30/2010 at 10:59 AM
Hi,

It has been a week and we haven't heard from you. We are going to close this issue now as we cannot reproduce the problem. If the problem persists, please feel free to log a new bug and we will be happy to take a look.

Thank you.
Posted by Microsoft on 3/23/2010 at 9:34 AM
Sounds good. Thank you.
Posted by Pedro G. Dias on 3/22/2010 at 10:45 PM
I'll try to find the time to reproduce this, please allow the full week.

Posted by Microsoft on 3/22/2010 at 1:46 PM
Hi,

Thank you for your response. However, we are still unable to reproduce the issue. Can you please attach a sample project? If we don't hear back within 3 days, we will close this issue.

Thank you.
Posted by Pedro G. Dias on 3/4/2010 at 11:41 PM
I found the solution:
The bin folder was included as part of the Asp.Net project, this, somehow, affects the Content files for the setup project.

I discovered it when I was writing a smaller project to send over to you - I noticed that the bin folder was not there.

Suspected explanation of the error:
Because the bin folder is normally created during build of the ASP.NET project, the process that extracts content files has probably already run, and thus does not find the content files from Log4Net and other referenced dlls.

This is no longer an issue for me, as I was able to start building the installer, but it should be looked into in case some other developers need to include their bin folder for whatever reason.
Posted by Microsoft on 3/4/2010 at 10:22 PM
Thank you for reporting this issue.But we are unable to reproduce this bug.Could you please attach a zipped project to help us reproduce it?
Posted by Microsoft on 3/4/2010 at 7:02 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.