Problem building Managed C++ project with Msbuild that has multiple assembly references

I have a VS2005 solution that includes a Managed C++ project as well as several C# projects. The C++ project references several of the C# projects. All projects in the solution reference log4net.dll (as an AssemblyReference).

My C++ project builds without any warnings using the VS2005 IDE. However, when I build the solution using MSBuild, I get zillions of warning messages such as:

log4net.dll : warning C4945: 'LogicalThreadContextProperties' : cannot import symbol from '<some path>\log4net.dll': as 'log4net::Util::LogicalThreadContextProperties' has already been imported from another assembly 'log4net'

For my managed C++ project, I set all references to be:

Copy Local: true
Copy Local Depencies: false
Use Dependencies in Build: false
Use in Build: true

When building with MSBuild, it is acting as if the "Use Dependencies in Build" flag were set to true for one of my C# projects. I have played around with many different combinations of project settings but I cannot eliminate these warning messages. They are more than annoying - there are so many of them that they slow down the build significantly.

The only way I have been able to eliminate them is to remove the project references from the C++ project and add the appropriate "/FU" options to the VC++ compiler command line. However, this is not really a satisfactory solution.

Answer this question

Problem building Managed C++ project with Msbuild that has multiple assembly references

alshami

Tarek Madkour MS wrote:
We have a fix for this bug. The fix will hopefully be rolled into VS2005 SP1 which should be released later this year.

If this is a blocking issue for you and you cannot wait until SP1, you can contact product support and request a private fix (QFE) for the issue. Please point product support to VS Whidbey bug #580380 in your report. We'll gladly provide you with a private fix that unblocks you until the SP is released.

It's probably worth mentioning that Microsoft does not charge clients for requesting QFE's; just in case you're wondering :)

I hope this helps.

Thanks,

So we can't get this private fix or QFE or whatever

Server Girl

Hi Mark,

Thanks for reporting this. We narrowed this down to be a bug in the VC++ build engine. Can you please log this issue on http://msdn.microsoft.com/productfeedback This will help you track our progress on a fix for this.

Thanks again.
Googlesyrop

Hi David,

I can't recall off the top of my head what the issue here was. It was a while back.

I'll go hunt it down and respond back to the thread hopefully by tomorrow.

Thanks,
Liel
Thanks for the reply, although I just changed my project to not use a shared output directory anways.

Nice to hear that its fixed.
carthegenian
Tarek,

Is there going to a knowledge base type patch for this issue I know its not a huge priority, but managers tend to freak out a little when they see lots of warnings during a release :-)

Thanks,

Alex
DOAHunterX
I am also interested in a resolution to this issue.
Sueva
I would like to get a hold of this fix - however Microsoft Technical Support says that they cannot give it out without an article ID. Is there an article ID I can give them

Cheers.
clarayeung
Hmmm... We were running into the same problem and I am currently on the phone with MS support. Unfortunately, the first tier guy I'm dealing with can't find any reference to this bug in their system. Is there an associated KB article for them to reference so they can dig it up quicker

Thanks!

Winthrop
GuyLowndes

You can refer the support person to this issue: http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx feedbackid=b7164cd2-d448-4083-b28b-690be1a9a391

They should be able to trace the bug this way.

If they still can't. Please have them contact me by email and I'd be happy to point them to the fix.

I think the problem is that this fix has not been requested as a QFE before (you're probably the first one) and your support person may be looking only in the existing QFEs database not in the whole product bugs database.

Thanks,
ArifKh

We have a fix for this bug. The fix will hopefully be rolled into VS2005 SP1 which should be released later this year.

If this is a blocking issue for you and you cannot wait until SP1, you can contact product support and request a private fix (QFE) for the issue. Please point product support to VS Whidbey bug #580380 in your report. We'll gladly provide you with a private fix that unblocks you until the SP is released.

It's probably worth mentioning that Microsoft does not charge clients for requesting QFE's; just in case you're wondering :)

I hope this helps.

Thanks,
DNA20

Has anyone discovered a workaround for this problem in VS 2003 yet

Cheers,

Ash
bobiav

The hotfix doesn't exist yet, so PSS can't hand it out. We have the bug internally in our database and it is going through the hotfix process right now. It will be at least a couple of weeks before it is ready.

Neil
jeremym1234

Until we have an actual hotfix that PSS can provide, there's nothing available for you to request. We are dilligently working on it and will post back as soon as it's available through PSS channels.

Neil
haal1

We're getting the same problem. A solution containing several VC++ and C# projects that we could build in 10 minutes on VS 2003 is now taking us over 4 hours and producing 5000 of these warnings when building from the IDE. We seem to be getting even more warnings when building from msbuild, though I'm still checking this.

This is a bit of a show-stopper for us so any suggestions appreciated.
Problem building Managed C++ project with Msbuild that has multiple assembly references

Answer this question