Publish web feature not including all dlls - by marlint111

Status : 

  Duplicate<br /><br />
		This item appears to be a duplicate of another existing Connect or internal item.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 637071 Comments
Status Closed Workarounds
Type Bug Repros 11
Opened 1/20/2011 1:54:46 AM
Access Restriction Public


ASP.NET MVC 2 application.

Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.

Please see:

It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).

Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?

I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
Sign in to post a comment.
Posted by Toma Bussarov on 11/1/2016 at 1:32 PM
Hello Microsoft,
seems like the duplicate you are referring to does not exists anymore (Connect shows Page not found). So bug is not fixed and duplicate is lost.
Posted by Microsoft on 10/18/2012 at 4:27 PM
Thanks. I have marked this bug as duplicate of the connect issue you have filed.
Posted by Donatas on 3/15/2012 at 1:34 AM
I have reopened this bug in here

There you will find attached solutions used to reproduce this bug as well as Word document with screenshots and steps to reproduce this bug.
Posted by Wrth on 4/12/2011 at 12:26 AM
I'm having a problem publishing WCF service which uses native c++ dll through CLI-layer. I attached sample project for reproducing the issue. Only the WCF service dll gets published to the bin folder, even if I manually copy the other DLLs to the bin folder before publishing.

I'm using:
Windows XP Professional SP3
Microsoft Visual Studio 2010
Version 10.0.40219.1 SP1Rel
Microsoft .NET Framework
Version 4.0.30319 SP1Rel

Installed Version: Professional

Microsoft Office Developer Tools 01018-532-2002102-70853
Microsoft Office Developer Tools

Microsoft Visual Basic 2010 01018-532-2002102-70853
Microsoft Visual Basic 2010

Microsoft Visual C# 2010 01018-532-2002102-70853
Microsoft Visual C# 2010

Microsoft Visual C++ 2010 01018-532-2002102-70853
Microsoft Visual C++ 2010

Microsoft Visual F# 2010 01018-532-2002102-70853
Microsoft Visual F# 2010

Microsoft Visual Studio 2010 Team Explorer 01018-532-2002102-70853
Microsoft Visual Studio 2010 Team Explorer

Microsoft Visual Web Developer 2010 01018-532-2002102-70853
Microsoft Visual Web Developer 2010

Crystal Reports Templates for Microsoft Visual Studio 2010
Crystal Reports Templates for Microsoft Visual Studio 2010

Microsoft Visual Studio 2010 Professional - ENU Service Pack 1 (KB983509) KB983509
This service pack is for Microsoft Visual Studio 2010 Professional - ENU.
If you later install a more recent service pack, this service pack will be uninstalled automatically.
For more information, visit

Microsoft Visual Studio 2010 SharePoint Developer Tools 10.0.40219
Microsoft Visual Studio 2010 SharePoint Developer Tools
Posted by Brian Bilbro on 3/25/2011 at 6:08 AM
I'm having the same issue where VS's publish feature is not copying all of the DLLs thare in the BIN folder.

Here's some more information is hopes to be able to reproduce this issue:

1) I have a Framework project that references these DLLs (there are MS DLLs so hopefully that helps with repro)
2) I have WCF services web application that references the Framework project.
Those above DLLs are in the bin folder.
3) When publishing, those DLLs are not including the publish destination

Other Info
1) I'm using VS 2010 SP 1
2) We also use TFS 2008 to build the application. The destination deployment folder also is not including those DLLs.

Posted by shareeef on 3/16/2011 at 8:59 AM
Any update on this? I am also noticing this on VS2010 sp1. I am running it on XP. I have a reference dll(.net 4.0) that inturn references log4net.dll (.net 2.0). The log4net.dll is not getting copied in the bin directory of the web folder. This is resulting in missing log4net.dll in the deploy package.

This is glaring!
Posted by Microsoft on 3/8/2011 at 12:13 AM
Hi, given that we have not heard back from you, we will go ahead and close this Connect Issue. If you get a chance to review and provide the information requested earlier, you can go ahead and reactivate this issue.(Click “Edit this item” button on the site and change the “Status” to “Active”)
Posted by Microsoft on 2/24/2011 at 11:29 PM

Sorry for bothering. Is there any update?

It would be greatly appreciated if you could provide us with that information as quickly as possible.

Thanks you
Posted by Microsoft on 2/21/2011 at 1:55 AM
Hi guys,
Could you please provide us with a sample project zip?

Please name the zipped file Feedback-637071-[your name].zip.
You can upload the file to workspace:
Password: F^p#w)54n)*d)

It would be greatly appreciated if you could provide us with that information as quickly as possible.

Thanks again for your efforts and we look forward to hearing from you.
Posted by Peter LaComb on 2/18/2011 at 5:29 AM
Actually, a slight correction - the references on ClassLibrary1 include ClassLibrary2 & ClassLibrary3 (won't build otherwise).

All of these are project references, copylocal true.

And the content of MVCApp\bin when built locally includes all expected files.
Posted by Peter LaComb on 2/18/2011 at 5:27 AM
I have the same issue, though instead of external assemblies, it's an additional project:

MVCApp references ClassLibrary1 (Making use of a new ClassLibrary1.Foo())
ClassLibrary1 references ClassLibrary2 (Making use of a new ClassLibrary2.Bar())
ClassLibrary2.Bar references ClassLibrary3 (ClassLibrary2.Bar is a ClassLibrary3.Widget<T>)

When I publish MVCApp, ClassLibrary1 and CLassLibrary2 are included in the output, but not ClassLibrary3. This causes the app to fail at startup. The content of the built deployment package and the results of just right-clicking the project and publishing are the same.
Posted by Microsoft on 2/18/2011 at 4:04 AM

Sorry for bothering. A perfect repro is a basic condition to troubleshoot an issue. Could you please help to confirm the repro steps? In your description you said that ExternalAssembly2 is only used by ExternalAssembly1. What do you mean by "used"? Just reference from ExternalAssembly1 to ExternalAssembly2? Or you had some structs or methods of ExternalAssembly2 called in ExternalAssembly1?

It would be greatly appreciated if you could provide us with that information as quickly as possible.

Thanks you
Posted by Microsoft on 2/15/2011 at 12:27 PM
Hi Marlint111,

Thanks for reporting the issue. It looks like other people are also hitting the same issue here. However, I still can't repro the issue the way you're reporting. So please clarify the repro steps for me.

In the repro steps, you said that:
ExternalAssembly1 calls into ExternalAssembly2

Does it mean in ExternalAssembly1, you put some code like the following
ExternalAssembly2.Class2 c2 = new ExternalAssembly2.Class2()

Also, do you package your project using context menu item "Build Deployment Package" or do you use the command line?

We greatly appreciate your effort in helping us troubleshoot the issue.

Visual Web Development team.
Posted by Microsoft on 1/20/2011 at 10:23 PM
Thanks for your feedback.
We are routing 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.
Posted by Microsoft on 1/20/2011 at 1:58 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(