Errors with DLL Referencing loading Source on New Desktop

P

pete.navarra

Greetings all,

I am going to attempt to describe the issue that I am having in full.
I apologize ahead of time that this may be a long posting, however, I
have found no other solution to my problem.


I am working with a VS2003 .NET1.1 Solution Project. The Solution
contains 6 Projects:
CEC_MT, CEC_UI, Common, CommonUI, FISCommon, and FISCommonUI.


The Common and CommonUI are class library's that are for all
intensive
purposes static. We can't/shouldn't change any code in those
projects. The Build Order is as follows: Common, CommonUI,
FISCommon,
CEC_MT, FISCommonUI, and CEC_UI.


We currently have one workstation (CPU1) where this project compiles,
runs, and debugs just fine. We are attempting to add an additional
developer to work on this same project. We copied the Source Code
from the working workstation to the new developers machine (CPU2).
All running the same versions of all the controls, Stuido, and .NET.


When we fire up Studio on CPU2, we immediately receive 147 error
messages:


'Public Overridable NotOverridable Property BackColor() As
System.Drawing.Color' is declared in project
'Janus.Windows.GridEX.dll', which is not referenced by project
'CEC_UI.exe'.


The object in question is located in C:\Program Files\FIS. We have
approximately 10 objects that point to that directory, however, the
error is ONLY on this one DLL, Janus.Windows.GridEX.dll.


Nothing in the source code changed from CPU1 to CPU2. Trying to
solve
the issue, we redirected the References to point to the <project>\bin
directory. That causes the error messages to go away, however, this
doesn't help us because the references have to point to the C:
\Program
Files\FIS directory.


We checked all of the Project Properties, and the Reference Paths all
point to "C:\Program Files\FIS". Again, this same code works on
CPU1,
but not CPU2, and they "should" be identical builds.


Can anyone provide some guidance or something for us to try? We're
going on about 2 months of not getting past this. We only have one
machine where this source code works.


Thanks in advance.


Pete Navarra.
 
B

Bryan Phillips

Download Process Monitor from www.sysinternals.com (aka Microsoft) .
The tool is free and when you run it, it will tell you the registry and
file access of the system. You should look for the name of that DLL to
see what path Visual Studio tries when resolving that DLL.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top