I just "fixed" the same problem with my VS project. Visual Studio did always a rebuild, even if didn't change anything. Solution in my case: One cs-File had a future timestamp (Year 2015, this was my fault). I opened the file, saved it and my build problem was gone!!!

Yes, the gcroot<> line is at global scope. I wrote an ManagedCode-DLL based on a .NET-Assembly that is dynamically linked by a standard MFC application. The gcroot variable is created during DLL initialization (called via a procedure). Hopefully this will help you.. Currently I am working on a different approach (linked list class) to solve my problem. This seems to be the best solution as gcroot more like a "dirty" fix for something that can be solved in a more correct way, i suppose. ;) Thanks for your time

Well, thank you for your answer but that didn't help.. :( I'm using VC2003 and a .vcproj file to create the dll. The .NET library is linked inside(!) this dll as I want to use some of the implemented functions. The .NET library is linked via assembly reference only: AssemblyReference RelativePath="$(SolutionDir)\include\[.NET].dll" I can access the namespace and library classes at design time. The weired thing is that VC2005 created the [.NET].netmodule automatically (with the same project), but VC2003 does not. Looks like there is no (easy) solution for this bug and I have to use VC2005 to create the module file.. ;) thx -- modified at 6:16 Tuesday 28th August, 2007

No warning/error there either :) Mark Salsbery Microsoft MVP - Visual C++ :java: