VS2010 does complete rebuild based on completely unrelated file

Posted by Marc_75 on 1/9/2013 at 7:58 AM

Hi,

people that would like to have this issue fixed, should update their Sophos anti-virus engine to 10.2.2. For more information, refer to:
DEF82646, http://downloads.sophos.com/readmes/sesc_102_rneng.html

Marc

Posted by D.Howell on 4/16/2012 at 5:42 AM

Adding the unwanted dependency files to the ClNoDependencies item in the Microsoft.Cpp.Win32.targets file works for us (Windows 7/64-bit). This was needed for both the NVIDIA (nvdrsdb0.bin) file Dave mentioned on 3/30/2011 and the Sophos config file (config.bops). I found that it was also necessary to add a <LinkIgnoredFiles> item to the <ItemGroup> of the <Target Name="Link"> target in that same targets file.

Posted by Anton V. Kravtsov on 2/23/2012 at 4:50 AM

Adding irrelevant files to C++ ignore list (via ClNoDependencies, as proposed in the comments) doesn't work with VS2010 (no SP installed) on Windows 7 32-bit.
I've tried specifying both pure filename and the full absolute path.
I wonder whether this issue has been really fixed...

Posted by Baronics on 11/2/2011 at 6:53 AM

I'm running VS2010 SP1 and I'm still seeing this problem with the same SOPHOS ANTI-VIRUS\CONFIG\CONFIG.BOPS file being checked on all of my projects.

Adding ClNoDependencies helps for compiles, but I still see it in Link, RC and Manifest.

A fix would be appreciated.

Bill.

Posted by Marko Raatikainen on 8/15/2011 at 1:02 AM

Hello,

I just noticed this has moved to FIXED status. Which is very, very good news! :) The next thing I'd like to know is when can I have it. ;) Will there be some patch, will it be included in a SP, or how is it planned to be delivered?

Thank you very much for making the fix!

-Marko

Posted by Dave O'Rourke on 3/30/2011 at 1:40 PM

We're also hitting this bug. The unrleated file in our case is "C:\ProgramData\NVIDIA Corporation\drs\nvdrsdb0.bin". We've determined this using the project system logging method described in this helpful VS Project Team Blog post: http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx

It seems insane that MS Build (or CL) would care at all what happens to that particular file. We have a large, complex solution that takes around 30 minutes to rebuild, and this is causing a lot of unnecessary rebuilds. If there's no fix forthcoming from Microsoft, we need a workaround.

Posted by jschroedl on 3/29/2011 at 6:23 AM

This act of monitoring all file access during a build is very bad. We're facing the same issues -- AV software uses hooks which causes unrelated activity to trigger rebuilds. It's shocking that this is marked Won't Fix.

Posted by lutz.jacob on 3/18/2011 at 7:39 AM

We are facing the exact same problem on all of our developer machines after switching to VS 2010. This is a major problem for us as a complete rebuild usually takes about 15 to 30 minutes. It seams to happen at least after every update of Sophos antivirus signatures.
Using ClNoDependencies seams to have an effect to the compiler, so the sophos configuration file does no longer appear in the cl.*.tlog. But it is still there in all other stages like link, lib, mt, rc and so on. It's also not a real option to change hundredths of project files to exclude dependencies which may be located in different paths on different machines.
Those *.tlog files show many other unrelated files that just don't change that often. But some of them may lead to similar effects in other situations. I think there is a general problem in the design of the build process, not a specific minor problem with sophos. MS should consider changing the way how to detect which files are related to a build process.

Posted by Marko Raatikainen on 3/9/2011 at 1:53 AM

Hello Dan,

and thanks for the help.

I tried the ClNoDependencies change, but unfortunately it did not have the desired effect.

I first tried putting it in a property sheet, which is inherited in all projects.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
...
<ItemGroup>
    <ClNoDependencies Include="D:\DOCUMENTS AND SETTINGS\ALL USERS\APPLICATION DATA\SOPHOS\SOPHOS ANTI-VIRUS\CONFIG\CONFIG.BOPS"/>
</ItemGroup>
</Project>

The effect was that the file was now included in msbuild output like this:
...
ClInclude
    PreciseClock.h
ClNoDependencies
    D:\DOCUMENTS AND SETTINGS\ALL USERS\APPLICATION DATA\SOPHOS\SOPHOS ANTI-VIRUS\CONFIG\CONFIG.BOPS
CoreCppClean
    Debug\
...

But it did not change the outcome of the build. If the configuration file is changed, the compilation is done regardless.

...
Read Tracking Logs: (TaskId:17)
    Debug\cl.read.1.tlog (TaskId:17)
Outputs for D:\DATA\SRC\AA027813_HELSINKI\CISPD\LARGE_COMPONENTS\DEVICELINK\SOURCE\COMMON\IFC\TIME\PRECISECLOCK.CPP: (TaskId:17)
    D:\DATA\SRC\AA027813_HELSINKI\CISPD\LARGE_COMPONENTS\DEVICELINK\SOURCE\COMMON\IFC\TIME\DEBUG\PRECISECLOCK.OBJ (TaskId:17)
D:\DOCUMENTS AND SETTINGS\ALL USERS\APPLICATION DATA\SOPHOS\SOPHOS ANTI-VIRUS\CONFIG\CONFIG.BOPS was modified at 9.3.2011 11:39:39. (TaskId:17)
PreciseClock.cpp will be compiled. (TaskId:17)
...

I tried also to add the modification directly in the first project file in the build (we have ~70 projects in the solution). But that had the same effect.

Thanks for all the help you can give,

-Marko

P.S. I know it is not your job to educate the ignorant, but I am not really familiar with the concept of injecting into process and I would like to understand the background. Is it like using a different dll as a wrapper around the original? I would appreciate it, if you can give me pointers on where to study on the subject.

Posted by Microsoft on 3/7/2011 at 8:24 AM

Sorry Marko.
(1) My suspicion is that sophos is injecting itself into processes like CL: I have seen a Cisco tool do this on another customer site causing a very similar problem. It then chooses to read its config file.
Now, MSBuild incremental build works the following way: we inject ourselves into the CL process when we start it. We then monitor all the file system activity of the process. We write the list of reads and writes we see to files with the extension .tlog. Next time around we read those .tlog files in order to figure out whether to build. In this case we see the config file read and don't know it's not caused by normal compilation (eg., perhaps you #included it).

It looks like there may be a possible workaround. Try putting this in your project file
<ItemGroup>
<ClNoDependencies Include="<<<name of sophos file here, try relative path, then if not, full path>>>"/>
</ItemGroup>

Does that help? It looks like it may tell us to igonre tihs file.

Dan

Posted by Marko Raatikainen on 3/7/2011 at 1:54 AM

Hello Dan,

and thanks for your response.

Unfortunately I was not able to comprehend your response. Please take note that I am not a native English speaker nor am I an expert in msbuild system. Could you explain a bit more, please?

What could be the reasons why CL would determine the Sophos configuration file to be a dependency? Why is CL reading and/or writing the file? Can I get clues by increasing the log verbosity of msbuild? Or is there some other way I could help you investigate the issue?

Sophos is an anti-virus software and it is being mandated by company policy. Unfortunately I cannot thus disable it. Even to try things out. :/

Thanks for any assistance you can give,

-Marko

Posted by Microsoft on 3/4/2011 at 9:13 AM

Marko, your point is quite reasonable. However, the mechanism we use to do incremental build intercepts all reads and writes done by the tool (CL, here). We treat the tool as an opaque entity and do not attempt in general to determine whether the file was really #include'd or is random. I'm wondering whether Sophos has injected itself into the CL process somehow -- somehow CL is reading its config file.
As a workaround can you disable Sophos for CL.exe or for your source tree or something like that?
thanks, Dan

Posted by Microsoft on 3/3/2011 at 6:49 PM

Thanks for your feedback.

We are rerouting 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 3/3/2011 at 9:13 AM

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)

Posted by jeremy.sketchup on 8/10/2012 at 8:17 AM

We had the same problem on a large team and our solution has 80+ projects, so the workaround of editing the Microsoft.Cpp.Win32.targets file was unappealing to us. I took an approach that has worked beautifully. Some may say that it's a total hack, which I'll admit it is, but it's incredibly simple and it works for now until Microsoft fixes it.

I wrote a tiny desktop tray app in C# that monitors the CONFIG.BOPS file, and whenever the timestamp changes, it sets it back to an old date using File.SetLastWriteTime without modifying the file contents. The app must be run as administrator on Windows 7, but that's fine for us as our staff all has admin rights to their PCs. Done!

VS2010 does complete rebuild based on completely unrelated file by Marko Raatikainen