Resource in a dll

  • Thread starter Thread starter mphanke
  • Start date Start date
M

mphanke

Hi,

I have an application that works fine when compiled as an executable.

But it is designed to be a plugin also at the same time, by compiling it
as a dll. I have a problem with resources when compiled as DLL. The
error always says there is no resource file named
"TESTNS.Toolbar.resources" - but it is definetly there. Is there a huge
difference in the linker producing a dll or an executable concerning
resources?? I assume it is something about the namespace, is this possible?

Thanks for your help,

Martin
 
Hi Martin,
I have a problem with resources when compiled as DLL. The error always
Click to expand...
says there is no resource file named "TESTNS.Toolbar.resources" - but it is
definetly there.
Is the "TESTNS.Toolbar.resources" an assembly resource file?
Do you mean it is still listed in the project's solution explorer window?

If so, how about remove it firstly then add it again(by using "Adding
Existed Items...")?


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Hi Gary,
Is the "TESTNS.Toolbar.resources" an assembly resource file?
Do you mean it is still listed in the project's solution explorer window?
Click to expand...
No, it is a .resx-File(containing icons) which resides in the VC.NET
project.
By error I meant an exception is thrown, when the application is loaded
as a plugin inside the plughost. There is no error if executed and
compiled as an exe-file. The exception even occures if I explicitely
link the resource-file into the project, and at this point I got
completely confused, about what is going on...

Is the problem maybe in one of this lines??

System::Globalization::CultureInfo* ci =
System::Threading::Thread::CurrentThread->CurrentCulture;

//this is the point where the application crashes when compiled as dll
System::Resources::ResourceManager *tbMan =
new System::Resources::ResourceManager(S"TESTNS.Toolbar", asmTESTNS);

//This happens 18 times for all the Icons included
imgLToolBar->Images->Add(static_cast said:
If so, how about remove it firstly then add it again(by using "Adding
Existed Items...")?
Click to expand...
Already tried this one. I'm working with VS for 6 yrs. - I'm used to
quiet some freaky behaviour....
 
Hi Martin,

Thanks for your detail information, we will perform some investigation on
this problem and reply you as soon as possible.


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Hi Martin,

In order to isolate your problem effectively, would you please upload a
small self-alone project(zipped) to us if possible?(you can send it as an
attchment with reply this message or just email to me, juse remove the
"online" phase of my emaill address)


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Hi Gary,

Sorry, I forgot to post a final reply.

I created a new project and inserted everything manually - afterwards it
worked fine. I don't really understand what the difference is since all
the settings are the same...

Thanks alot for your support. Have a look at the "using Forms in a DLL"
thread, I posted couple things in there.

It seems like the resource file was included in the manifest, but the
images where empty. One of the problems might have been the
$(SafeInputName)-Macro, but I'm not sure at all. If I experience this
type of behaviour again, I will email it to you. Further I will check
whether I can extract a copy from the nightly backup, if I can do so I
will email the whole project to you.

Regards,

Martin
 
Got mine to work. Really friggin weird.

The name of the project MUST MATCH the name of your root namespace. In my case, my project name was MAP, and the root namespace I was using was ROFMap. The form was ROFMap::frmViewMap. The manifest root (looking in the dll) was MAP. The second exe (that was inheriting from the first) was looking for MAP.frmViewMap.resource. I ended up changing the name of the project from MAP to ROFMap and recompiled. Everything works fine now....

I guess the moral of the story is don't change what MS puts in the form at all ;)
Ok, really. The project name and the namespace root must match inorder for everything to work well. Give it a try.

GE

PS> I created two little test programs to try this. If this is EXACTLY your problem, I'll upload them so they can look at it..
 
I finally got mine to work (After amonth of fiddle with is). My project name was MAP, and the root namespace I was using was ROFMap (Important). So the form in question was ROFMap::frmViewMap. The second EXE (Which was inheriting from frmViewMap) was actually looking for RootNamespace.FormName.resources (ROFMAP.frmViewMap.resources). It couldn't find this, because the rootnamespace is taken from the projectname (MAP). So my second project was looking for MAP.frmViewMap.resources.

I went back and renamed my initial DLL project to ROFMap, and recompiled. Everything came up the first time (Well, after the thunderstorm messed with my puters).

For your project to work, your project name has to be TESTNS. I would change this to your project name and try again.

GE

PS> If you look in the dll, the manifest will not show exactly what resources are in it.
 
SOrry if this posts 3 times. I kept getting an error trying to post (Not in IE, but as a reply from microsoft).


I finally got mine to work (After amonth of fiddle with is). My project name was MAP, and the root namespace I was using was ROFMap (Important). So the form in question was ROFMap::frmViewMap. The second EXE (Which was inheriting from frmViewMap) was actually looking for RootNamespace.FormName.resources (ROFMAP.frmViewMap.resources). It couldn't find this, because the rootnamespace is taken from the projectname (MAP). So my second project was looking for MAP.frmViewMap.resources.

I went back and renamed my initial DLL project to ROFMap, and recompiled. Everything came up the first time (Well, after the thunderstorm messed with my puters).

For your project to work, your project name has to be TESTNS. I would change this to your project name and try again.

GE

PS> If you look in the dll, the manifest will not show exactly what resources are in it.
 
Sorry for the multi post. When I hit post, it said it encountered an error and couldn't post. So I retried 2 more times.. I love technology!!!

GE
 
Hi Martin,

I am delight to know that the trouble problem had gone away with a new
project, if you have any inconvenience to upload the sample project, don't
mind it, it's OK!


Good Luck!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Back
Top