views:

31

answers:

1

I will be creating a series of projects set up to build COM objects. I attempting to create a property sheet (.vsprops file) which will set up the builds for each project. One of the things I am doing with the properties file is customizing the location and names of the files created by the MIDL compiler. Here's the code I use for this:

<Tool
    Name="VCMIDLTool"
    TypeLibraryName="$(InputName).tlb"
    OutputDirectory="$(RPCDIR)"
    HeaderFileName="$(InputName).h"
    DLLDataFileName="$(InputName)_dlldata.c"
    InterfaceIdentifierFileName="$(InputName)_i.c"
    ProxyFileName="$(InputName)_p.c"
/>

RPCDIR is a macro defined before this section of the property file. This works great for compiling the code. When I build my project, these five files are created with the correct names in the location I specified in the RPCDIR macro. My problem is when I try to clean the build. The clean successfully deletes four of the files, but the DLL Data File does not get deleted. I'm especially confused that some are deleted and one is not - I would have thought that either they would all be deleted or none be deleted rather than a split like this.

Does anyone know how I can customize the clean build to correctly delete these files? Optimally any changes I need to make would be in the property sheet so that I can share it with other projects, but if that's not possible then I'd like to at least be able to do it in the project file. Thanks in advance for any help you can offer!

A: 

Not your problem, it is a bug in the build system. The dlldata.c file doesn't get deleted using a regular build either. There aren't enough diagnostics available in the msbuild .log files to see what target fumbles this. I'm guessing it has something to do with the <FilePatternsToDelete> item in the Microsoft.CppClean.targets file.

I recommend you report this problem at connect.microsoft.com

Hans Passant
I submitted the feedback at connect.microsoft.com as suggested, but unfortunately they are no longer accepting feedback for Visual Studio 2005. Looks like I'll have to live with this or create a workaround until we are able to upgrade our codebase to Visual Studio 2010.
CyBri2000
I was talking about VS2010.
Hans Passant