Jump to content
  • Advertisement
Sign in to follow this  
dysplaced

[.net] New Component DLL Problem

This topic is 4816 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm completely new to .NET but I have programming experience in other areas. I'm trying to implement a new ControlElement which uses my DirectX 3D Engine to display something (useful for Level Editors etc.). My Problem is that while I could get a simple Testcomponent up and running, as soon as I #include the Main Header file of my Engine, the Project doesn´t compile anymore (the Engine itself is a .lib). I get an unresolved Link Error (LNK2019) saying the symbol "_main" is not defined. This confuses me because I thought .DLLs don't need a main-function (I tried implementing DllMain(), same result). When I tried to track down the problem, I found two examples that cause the error (I think there will be more, I only tried changing the first) - both are inline functions (one is the copy-constructor of my String-Class, the other the GetRow() Function of my Matrix3-Class). I don't have a clue why and how these specific functions cause this error, can you help?

Share this post


Link to post
Share on other sites
Advertisement
EDIT: I found out a little more about my problem but still have no clue how to solve it. If I create a normal .DLL (New Project->Win32->Win32-Project->DLL) there is no problem if I #include my Engine Header. When doing the same thing with a new .NET Windows-ControlElement Library, I get the Error described above. Help!

[Edited by - dysplaced on September 9, 2005 5:29:48 AM]

Share this post


Link to post
Share on other sites
Hmmm, it sounds like you're mixing unmanaged C++ and .Net in ways that aren't supposed to work. If you want to mix the two you either need to create a COM wrapper for the .Net component or using managed C++ (or another .Net language) instead of Win32.

Share this post


Link to post
Share on other sites
I hope I understood what you mean: The error occurs because my Engine is written in plain old C++ and the .NET project only works with managed C++?

I tried your second suggestion and created a new empty .NET project. I filled it with my Code and got a library that works exactly like the normal one - including the unresolved link error.

Did I get you wrong, do something wrong or do I need to try the COM Solution (which would create new questions for me since I also never used COM except for DirectX Initializing)?

Share this post


Link to post
Share on other sites
dysplaced,

I'm assuming right away that you are using Managed C++ to do your coding here (mostly because if you were using regular C++ you wouldn't be targeting .NET, and you were using, say, C#, the code wouldn't even get to linking).

I'm also assuming that you're talking about a "Windows Forms Control Library", which is presumably what you want.

If you're completely new to .NET, I don't encourage MC++ to be your first venture into the technology. (Especially not Pre .NET 2.0! MC++). I would learn how the CLR and CLI work first (using say C#) and then delve into mixing the two. Once you start mixing managed and unmanaged code, things get dicey _really_ fast if you don't know what you're doing.

This sounds like a standard C++ linking error though. For the most part, you can include just about any include files/libraries in a MC++ project. Generally you then write managed code that utilizes the unmanaged API that you've exposed. The old code can be standard C or C++, its designed to work that way. It really works quite well. As a matter of fact, I just wrote a Managed C++ library two days ago that uses Freetype to render TrueType Font bitmaps on the fly for a game. The game is written in C#, and Freetype is of course plain old C. I had no troubles including the headers and linking to the library and then using that C code in a MC++ library which is used by a C# game. Except that Freetype uses a variable named 'generic' in many of it's classes and 'generic' is a reserved word in MC++. Just changd them all and it worked fine.

Anyways, back to what could be causing your problem. Recompile your engine _and_all_dependant_libraries_ using your new VC++. This is a pain in the butt. It takes time. Your engine or dependant libraries may depend on Platform SDK stuff. (If you recompile and get all kinds of 'cannot find windows.h or uuid.lib or stuff like that'). If so, you need to download the platform SDK and add it to your include/library paths. You may need to change a few small things to get it to compile.

When you recompile the engine and dependant sources, they must all be compiled using MultiThreaded DLL mode! (Either MT DLL Release or MT DLL Debug, your choice). The SubSystem needs to be set to either SUBSYSTEM:WINDOWS or "NotSet" (which is only possible with the newest compiler). The Native->CLI interface will not work with any code linked to the Single Threaded Common Run Time.

If you decide to skip recompiling a certain library you're just asking for pain and misery. There are radical changes in memory management and allocation, and libraries compiled to utilize the old memory routines will corrupt and break things :-). It's fun. I've spent hours debugging wierd memory corruption issues that were the result of mixing incompatible CRT's. (Even in standard C++, using a lib compiled for a 6.0 CRT will often break in a application compiled for the 7.0 or 7.1 CRT).

Check your engine source to see if you used any "#pragma comment(lib, 'something.lib')" lines that automatically including a library. This library also needs to be compiled using MT DLL. It sounds like something (maybe even your new library) has been configured to use SUBSYSTEM:CONSOLE, and VC++ wants to link the CRT to your main() method, which of course does not exist.

Subsystem is at:
[Project Properties]
Configuration ->
Linker ->
System ->
SubSystem

ST/MT DLL setting is at:
[Project Properties]
Configuration ->
C/C++ ->
Code Generation ->
Runtime Library


Like I said, it's really important that you recompile all of your old code and get it working with the new VC++ compiler using the right settings. Then at that point you can focus on actual integration errors, rather than silly LINK_NOBODY_KNOWS_THIS_CODE errors.

Didn't mean to write a book :-). I'll monitor this thread for a bit and check up on how you're doing.

-Dave

Share this post


Link to post
Share on other sites
Ok, found it. It was the Runtime Library of my Engine.
But seeing how much Trouble it is to implement a custom component (I have problems debugging it now etc.), I think I'll stick to the much simpler variant of using the Engine directly in the Form which was very easy to do so far. Anyway, thanks for the help!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!