Troubleshooting Assembly Linker Error, C++, VS 2005

Question

Using Visual Studio 2005 with the latest Service Pack.

I have a managed C++ solution with 38 projects (that I've just inherited.) When I build this solution, I'm receiving the following error from the Assembly Linker:

"error AL1019: Metadata failure while creating assembly -- The process cannot access the file because it is being used by another process."

I'm kind of at a loss as to how to resolve or troubleshoot this. The surrounding steps in the build output are:

1. Writing Resource File... Done.
2. Compiling resources...
3. Linking...
4. Creating library [PATH]\[FileName].lib and object [PATH]\[FileName].exp
5. Creating resource satellites...
6. Error Occurs Here.

There is no difference in the results between Build vs Rebuild vs Project Only with or without Cleaning the Solution first. And, in all cases, the DLL, EXP, ILK, LIB and PDB files for this project are created.

I've compared this particular project to other projects in the solution that are structured similarly and see no appreciable differences. I've looked at the batch files and temporary rsp files that get generated during the build process and see nothing that jumps out there either.

My current speculation is that the Linker is trying to embed the Intermediate Manifest file into the assembly while something else is still trying to write to the same Intermediate Manifest file (or to the assembly itself.) Though, I'm kind of guessing at this point.

If anyone knows how to resolve this or has any insight as to what else to look into to try and troubleshoot I'd greatly appreciate it. Thanks.

A sanitized version of the end of my build log, if it helps:

    /ASSEMBLYRESOURCE:".\Debug\[Namespace].[ErringProject].dll.licenses" 
    ] 
    Creating command line "link.exe @[Path]\[ErringProject]\Debug\RSP00030A20042852.rsp /NOLOGO /ERRORREPORT:PROMPT" 
    Creating temporary file "[Path]\[ErringProject]\Debug\RSP00030B20042852.rsp" with contents 
    [ 
    /out:"[OutputPath]\[Namespace].[ErringProject].dll" 
    /c:Run 
    /template:"..\..\..\..\..\Run\[Namespace].[ErringProject].dll" 
    /embed:".\Debug\[Namespace].StringsNT.resources" 
    /embed:".\Debug\[Namespace].Strings.resources" 
    ] 
    Creating command line "al.exe @[Path]\[ErringProject]\Debug\RSP00030B20042852.rsp /nologo" 

Answer 1

Try navigating directly to the problem file and see if you can delete it yourself. If you can't, rename it (yes, sometimes you can rename files even though they're in use) and try the build again. Sometimes something holds the file open and even a clean can't delete it.

If the above doesn't work try adding an exception to your build directory in your anti-virus software. I've had this issue with Symantec Endpoint Protection. As soon as the file was written and closed, it would open it to scan it right when the next step was to edit that file. Needless to say, the file was "in use" and caused the build to fail.

Answer 2

This is a problem that seems relativelty common with VS2005, but MS closes the issue as a non-repro (I suspect the problem is connected to some interaction with other applications/drivers installed on the system that MS doesn't have on their test beds).

• https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=90699
• http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=106105

I've heard that people have worked around the problem by changing the output directory in the project settings, but I'm not sure how permanent or reliable the workaround is. Another thing to try (if it's possible for you and hasn't already been done) is to update to to SP1 or VS2008.

Answer 3

Finally tracked this down to the order of the XML Filter Collections in the Project file when using the external resource compiler (i.e. resgen.)

The failing project had, in its Proj file:

<files>
    <Filter Name="Header Files" ...>
        ...
    </Filter>
    <Filter Name="Resource Files" ...>
        ...
    </Filter>
    <Filter Name="Source Files" ...>
        ...
    </Filter>
</files>

Switching that to:

<files>
    <Filter Name="Header Files" ...>
        ...
    </Filter>
    <Filter Name="Source Files" ...>
        ...
    </Filter>
    <Filter Name="Resource Files" ...>
        ...
    </Filter>
</files>

Did the trick.