Sorry, that does not help, because of the linker-dependencies. If I remove the dependency, I get a linker error. Is there any setting, switch, or something else, that causes VS to rebuild a project even if nothing has changed?

Hello, i'm having an annoying problem with VS2008. My solution contains about 20 projects. VS does a total rebuild everytime. If I change nothing, but simply restart the application, rebuild. If i change one file of one project (normaly it would only compile/link the changed project), rebuild. The websites i've found on the net are no help (MS-Support). The projects are linked by dependencys and not by the project-linkerinput-settings. Please help :)

modified on Tuesday, July 28, 2009 9:33 AM

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

Thank you for the answer, I'm fairly new to this topic (gcroot). This is the new code according to your suggestion. parameters=__gc new System::Collections::ArrayList(); But still, the same exception is raised when I try to create the ArrayList... Any idea? :-D

Hello, this question may come from a very wrong approach:wtf:, feel free to suggest a better way to solve this :-D I want to store a global dynamic list of structs inside a managed code dll. First I create the array list

gcrootSystem::Collections::ArrayList\* parameters;
parameters=new System::Collections::ArrayList();

But i get a very weired exception during runtime: Handle has not been initialized when creating the ArrayList. How can I initialize this variable the correct way? Thx 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

I'm currently using VisualStudio2003 (and cannot change due to the fact that other team members are using it too). My current project uses managed code to dynamically link a .NET-DLL into my program, works so far. The only problem is, that to compile and link this DLL I need a [dllname].netmodule file, which can only be generated with VisualStudio2005. The file is generated by linking the dll into my project (references) and automatically used when the dll is loaded. VC2003 does not generate this file automatically, but if it is not present, the DLL cannot be used (access violation). Using google I found this to be a bug in VC2003 but no appropriate solution. Is there any way to generate this file with VC2003 (compiler switch, etc.) automatically?? Thx in advance

The project option "Character Set" could be what you are looking for. There are three settings avaiable: - Use Multi-Byte Character Set - Use Unicode Character Set - not set This option can be set in the project configuration->General.

(i renamed the caption to "minor", seems more appropriate) workflow: 1. DLL 1a. creating the dll.h file with function prototypes 1b. creating the dll.cpp file with function implementation (the dll itself does not use the functions, so no linking check here!) 2. app 2a. dynamic loading of dll using dll.h I wanted to ensure the correct calling of functions in the app using the .h file: (i have cut all the class stuff etc.) [dll.h] int DLLInit(char* DLLInfo); [app.h] #include "dll.h" typedef bool (*DLLINIT)(char* DLLInfo); DLLINIT pDLLInit; pDLLInit= (DLLINIT)::GetProcAddress(m_DLL, "DLLInit"); Is this possible (or even useful) in any way? -- modified at 5:50 Thursday 23rd August, 2007

hum, actually, i was more saying that the compiler (or maybe the linker in fact) will throw a warning if you declare a function (in a .h mostly) that is never defined... This is a helpfull warning indeed ;), VS2003 fails to warn you about this.

Why would it ? Function overloading is possible in C++ and you don't need to have a declaration for your functions. So, in your case you have a declaration of a function but no body for this function. As long as you don't call that function, everything will be fine. But once you call that function, you'll get a linker error. Okay, I called the function and finally :-O got a linker error, I was expecting an error during compiling... I developed using Delphi the last 5 years and the ambigious overloading of types/variables/function C++ without any visible effect is driving me crazy... In Delphi you had to add OVERLOAD or use a typecast.. The main reason for this problem: - i want to create a dll that can be called from another app, using dynamic linking - works so far - I changed the implementation of a function (by accident) and got a very confusing exception after calling the function from the dll but no compiler error, though i linked the header file from the dll.

Hello, I have a major problem with the .h header files. The Compiler (VS2003) does not seem to care about my function definition in the header file if implemented in another .cpp file. Here is an example: [myfunc.h] #pragma once int DLLInit(char* DLLInfo); [myfunc.cpp] #include "myfunc.h" int DLLInit(int DLLInfoInt) { return 0; } I seem to be missing the whole point of a header file if the compiler does not detect the false declaration of variable name and type.... :wtf: I want to include the header file in the project using the dll, too, so it is important to check parameter and type of function parameters, etc.:confused: Maybe this is a very simple problem but I can't find a solution yet.. Any help? thx in advance