Search

strange file not found error: xml documentation file renamed during incremental build by btj-agilent

Closed
as Won't Fix Help for as Won't Fix

7
0
Sign in
 to vote
Type: Bug
ID: 470485
Opened: 6/25/2009 7:35:08 PM
Access Restriction: Public
0
Workaround(s)
6
User(s) can reproduce this bug
This appears to be an old bug: http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/8a2f4af8-7a57-454f-aa7d-684f3f89acf3/

Here is the reply that was given by Microsoft when this was first reported:

Simon,

It looks like you've revealed an interesting bug in the Visual Studio (C#) project system. This is not an MSBuild issue specifically. It turns out that the project system temporarily renames the XML file until the end of the build, so there's no way to access the doc file by its actual name during the build. (Note: even the "AfterBuild" target is still technically part of the build).

This is an IDE-only problem, and you should never see this on command-line builds.

--Sumedh (MSBuild Team)
Details (expand)
Product Language
English

Version

Visual Studio Team System 2008
Operating System
Windows Vista
Operating System Language
English
Steps to Reproduce
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/8a2f4af8-7a57-454f-aa7d-684f3f89acf3/

Or, try to copy the XML documentation file in a post-build event. It will often fail during an incremental build (whenever the compiler isn't run because everything is up to date).
Actual Results
File not found.
Expected Results
File is found.
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

Sign in to post a comment.
Posted by NT AUTHORITY on 1/20/2012 at 12:05 AM
Visual Studio 2008 SP1 and the bug is still existing
Posted by Microsoft on 7/1/2009 at 4:19 PM
There's no action required on your part. We do review the top customer issues again for each release.

Thanks!
-Sean
Posted by btj-agilent on 7/1/2009 at 8:44 AM
Do I need to re-submit this issue to ensure that "we can address this in a future release", or do you automatically re-review "will not fix" defects before each release? If I do need to re-submit, what would be the appropriate timing?
Posted by Microsoft on 6/30/2009 at 5:42 PM
I'd like to thank you for your feedback. Unfortunately, the issue you are seeing is actually a known side-effect of design trade-off that we had to make back in VS 2005 to support intellisense. Unfortunately, fixing this is a large change and is likely something we would consider if we were to make significant changes to the xml doc comments feature.

The problem is that for performance reasons, the xml index service (which provides doc comments, to Intellisense, Object Browser, etc) keeps lock on the files which it is reading. As a result if you tried to build an xml doc comment that was locked, the build would fail. In order to fix this issue, we implemented a service that a tool such as build could use to request removing the lock which fixed the problem for some scenarios but not in scenarios where you had a second instance of Visual Studio which also had a lock on the file. We determined that we could solve this case and a few more by renaming the xml doc comment file before deleting it. As a result, you observe the side-effect in your builds.

I'm resolving this as won't fix for the current release but I hope that we can address this in a future release.

Thanks!
-Sean Laberee
VS Platform Team
Posted by Microsoft on 6/29/2009 at 3:59 AM
Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
© 2013 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement