Multiple symbols errors

  • Thread starter Thread starter Jason Hurder
  • Start date Start date
J

Jason Hurder

Hey folks,

I think this is a configuration issue. I have 3 projects running under
one solution, 1 is a Windows service, 1 is a administration module and
another a class library (dll) that is used by the service. Some files
are shared among the projects, like user settings. I am "linking" the
shared files to the projects by using the "Open link" option when adding
an existing item to a project. However when I compile, I get the age-old
"multiply defined reference" error a couple of hundred times. The reason
is because the service includes a link to the shared file, and the class
module includes a link to the shared file. The service has a reference
to the class library and because of this, the compiler finds the objects
multiply defined. In the C++ days, this was cured with #ifdef
FILE_NAME....#endif. Not that i like that answer, it worked. Does anyone
know how to get around this? Thank you much!

Jason
 
Jason Hurder said:
Hey folks,

I think this is a configuration issue. I have 3 projects running under one
solution, 1 is a Windows service, 1 is a administration module and another
a class library (dll) that is used by the service. Some files are shared
among the projects, like user settings. I am "linking" the shared files to
the projects by using the "Open link" option when adding an existing item
to a project. However when I compile, I get the age-old "multiply defined
reference" error a couple of hundred times. The reason is because the
service includes a link to the shared file, and the class module includes
a link to the shared file. The service has a reference to the class
library and because of this, the compiler finds the objects multiply
defined. In the C++ days, this was cured with #ifdef FILE_NAME....#endif.
Not that i like that answer, it worked. Does anyone know how to get around
this? Thank you much!
Click to expand...

Why not redesign those files so that they can be put into one common
assembly and just reference them?
 
So you mean to make a new project? Doesn't a project have to have an
output of a dll in order to be referenced?

Also, I should mention that I have these files under their own namespace
("FpHost.Shared"), and include them in my projects with "using
FpHost.Shared;"
 
Jason Hurder said:
So you mean to make a new project? Doesn't a project have to have an
output of a dll in order to be referenced?
Click to expand...

Yes. It sounds like this is common functionality that should be packaged
into a common library, hence an assembly exposing the classes.
 
Dan is giving you some solid advice. From a security standpoint sometimes
you really need the settings being read from within the project though. If you
need such security, you can change the shared file to have internal visibility.
That way, the code included in both projects will only be visible within those
two projects. They can each have their own versions, without any conflict
and you should be good to move on to your next problem.
 
Back
Top