.NET 3.5, Windows Forms and DirectX
Hey!
So, I got to do a little work on my at-home project this weekend (not lots, but a little). One of the things that I'm starting to play around with is Windows Forms in .NET. So I thought I'd do a little editor work, migrating from a pure Windows application into a .NET forms based app. Seems like a good idea, right?
Well, to a point it was. I got the form build, a simple layout setup and then I went to link in my existing libraries.
No go. When I tried to call a static initializer in my library, I got the following linker error:
__clrcall? That shouldn't be an issue. The library isn't a CLR library ... is it? A little investigation of my library indicates that it isn't. So. for fun I decided to explicity declare the method in question as __cdecl. Doing so (just adding __cdecl to the method signature) resulted in the following error:
Well now. That certainly gives us a bit to chew on. Why does it think that the new form I've created is a *pure* clr app? I just asked it to create a Windows Form app, using .NET 3.5. In Visual Studio 2008.
OK, so I'll just set the clr type to non pure. Simple enough. Let's see, where's that setting ... under linker probably ...
Nope.
OK, under C/C++ then
Nope.
....
Wait, where the Fuzzy Hell is it defined? Looking in the C/C++ Command line view, the value is shows up ( /clr:pure, for those wondering ).
So, I start at the top (normally I start at the bottom of lists ... things tend to be at the bottom of piles, but this time, I had a gut feeling) and look in the 'General' section.
Lo and Behold, there it is, under 'Common Language Runtime Support'.
I *suppose* it makes sense, but you know, that seems like an odd place for it to live.
Anyway, linking with just a simple CLR option resolves the issue and all is once again cool in the world.
So, I got to do a little work on my at-home project this weekend (not lots, but a little). One of the things that I'm starting to play around with is Windows Forms in .NET. So I thought I'd do a little editor work, migrating from a pure Windows application into a .NET forms based app. Seems like a good idea, right?
Well, to a point it was. I got the form build, a simple layout setup and then I went to link in my existing libraries.
No go. When I tried to call a static initializer in my library, I got the following linker error:
1>Sanity_2.0.obj : error LNK2001: unresolved external symbol "public: static void __clrcall Wanton::Graphics::CViewportFactory::Init(void)" (?Init@CViewportFactory@Graphics@Wanton@@$$FSMXXZ)
__clrcall? That shouldn't be an issue. The library isn't a CLR library ... is it? A little investigation of my library indicates that it isn't. So. for fun I decided to explicity declare the method in question as __cdecl. Doing so (just adding __cdecl to the method signature) resulted in the following error:
4>Graphics.lib(ViewportFactory.obj) : fatal error LNK1313: ijw/native module detected; cannot link with pure modules
Well now. That certainly gives us a bit to chew on. Why does it think that the new form I've created is a *pure* clr app? I just asked it to create a Windows Form app, using .NET 3.5. In Visual Studio 2008.
OK, so I'll just set the clr type to non pure. Simple enough. Let's see, where's that setting ... under linker probably ...
Nope.
OK, under C/C++ then
Nope.
....
Wait, where the Fuzzy Hell is it defined? Looking in the C/C++ Command line view, the value is shows up ( /clr:pure, for those wondering ).
So, I start at the top (normally I start at the bottom of lists ... things tend to be at the bottom of piles, but this time, I had a gut feeling) and look in the 'General' section.
Lo and Behold, there it is, under 'Common Language Runtime Support'.
I *suppose* it makes sense, but you know, that seems like an odd place for it to live.
Anyway, linking with just a simple CLR option resolves the issue and all is once again cool in the world.
Comments