Unable to instantiate non-conobject class. A spectre of doominess and an omen of end days.
by Christopher Lee · in Torque Game Engine · 07/01/2009 (9:37 pm) · 7 replies
We here at our game studio tend to run into the funnest and most interesting of errors. When compiling our Torque Game Engine (Version 1.5.2 using AFX) project.
The error we run into is this (Or similar to this):
...
Scenarios/Sephil Saga/particles/particles.cs (268): Unable to instantiate non-conobject class ParticleResource.
....
Now we've run into this error before and here's what seems to be going on. It seems that our C++ project in Visual Studio is not linking correctly and thus when trying to use the object declared in the unlinked C++ files it fails. That's all well and good but we don't know why this happens.
And then it gets stranger: We know how to fix this but we don't know why it works. If we exclude the files from the project, and then rename them and re-add them. It works just fine. In this example our team simply took out "Particle.cc" and "Particle.h" and renamed them "ParticleResource.cc" and "ParticleResource.h" and put it back in.
This works like a charm, and that is terrible. Mainly because these problems will happen and it takes a good long while for us to figure out it is THIS problem, and thus we waste many work hours only to rename a few files and have things magically work. Any ideas?
The error we run into is this (Or similar to this):
...
Scenarios/Sephil Saga/particles/particles.cs (268): Unable to instantiate non-conobject class ParticleResource.
....
Now we've run into this error before and here's what seems to be going on. It seems that our C++ project in Visual Studio is not linking correctly and thus when trying to use the object declared in the unlinked C++ files it fails. That's all well and good but we don't know why this happens.
And then it gets stranger: We know how to fix this but we don't know why it works. If we exclude the files from the project, and then rename them and re-add them. It works just fine. In this example our team simply took out "Particle.cc" and "Particle.h" and renamed them "ParticleResource.cc" and "ParticleResource.h" and put it back in.
This works like a charm, and that is terrible. Mainly because these problems will happen and it takes a good long while for us to figure out it is THIS problem, and thus we waste many work hours only to rename a few files and have things magically work. Any ideas?
About the author
#2
07/01/2009 (11:27 pm)
Yup. 
#3
I haven't been able to even Google this one very successfully because it's kind of hard to describe.
07/02/2009 (7:48 pm)
I've had this happen to me as well. It's some kind of Visual Studio issue- somehow the file in question is left out of the linking process; some kind of exclude list, because removing it from the project and re-adding it does not fix the problem. Doing a full rebuild doesn't fix it. Changing the release target doesn't fix it. The only fix I found is to rename the file! Even more depressing, you can rename the file, and it works, but remove/rename to original/add and rebuild, and it doesn't work any more- the problem is persistent and somehow tied to that file name!I haven't been able to even Google this one very successfully because it's kind of hard to describe.
#4
That's indeed a strange one. Which version of Visual Studio are you using? If 2005 or before, maybe 2008 solves the issue for you.
Is particle.cc and all the files that are referencing its exported symbols completely left out of the link? If not, VS is either creating an invalid link or maybe isn't properly executing the module's global init/exit code.
You could also try using the linker's /INCLUDE option to force a particular file into the link.
Still, this seems like really oddly broken behavior.
07/03/2009 (3:17 am)
That's indeed a strange one. Which version of Visual Studio are you using? If 2005 or before, maybe 2008 solves the issue for you.
Is particle.cc and all the files that are referencing its exported symbols completely left out of the link? If not, VS is either creating an invalid link or maybe isn't properly executing the module's global init/exit code.
You could also try using the linker's /INCLUDE option to force a particular file into the link.
Still, this seems like really oddly broken behavior.
#5
07/03/2009 (4:48 am)
We're using 2008 but you bring up some interesting fixit stratagems, thank you.
#6
BTW, for some real ugly hackfixing: just #include .cc files that get left out from within one of the .cc files that don't. Oh yeah, ugly.
Hope you can find some acceptable way around this.
07/03/2009 (5:04 am)
Hmm, on 2008... not that it surprises me.//Edit: the compile/link chain in VS2008 seems to have a number of issues (like the non-writeable .pdbs, too)BTW, for some real ugly hackfixing: just #include .cc files that get left out from within one of the .cc files that don't. Oh yeah, ugly.
Hope you can find some acceptable way around this.
#7
And then a year on down the road when we come back to it, really wonder what kind of drugs we were on!
Thanks for the help, I'm going to try the /INCLUDE option on my side and see if that doesn't help matters.
07/05/2009 (4:56 pm)
Oh man, that is an ugly hackfix! We could combine that with conditional compilation, something like: #ifdef __WINDOWS__ #include "something.cc" #endifAnd then a year on down the road when we come back to it, really wonder what kind of drugs we were on!
Thanks for the help, I'm going to try the /INCLUDE option on my side and see if that doesn't help matters.
Associate Ben Garney