bc30311 when linking 2 projects to static dll in same solution

[jkodroff]

Hi all,

I am getting a bc30311 error (Value of type 'x' cannot be converted to
'x'). Note that the source and destination types are the same.

I have run into this issue on 2 separate occasions. On both occasions,
type x was contained in a statically linked dll. The dll was linked in
2 projects in the same solution. One project depended on the other,
but both had to access type x and therefore needed the static dll
reference.

I am using Visual Studio.NET 2003.

The problem occurs only when first attempting to compile the solution
on a new machine. I tried a combination of rebooting, rebuilding, and
pixie dust and eventually got the code to compile, but I don't
understand why the problem is occuring and what a systematic solution
to the problem is.

Any help is appreciated.

[s.gregory]

Getting the exact same problem but with Web References in ASP.NET 2.0.

1. If you have a webreference [WR] containing an exposed class [X]
2. Then create say a wrapper class Y, which exposes class X
3. Then do the following in another place in the project (say a webform
page):

Dim oX as WR.X
Dim oY as New oY

oX = oY.GetX

you get the exact same problem.

I've noticed another old thread on the problem which even had some
replies from MVP's, but didn't really come to a conclusion.

http://groups.google.com/group/micro...15eee69cb05744

This has surely got to be a bug in the IDE, as you can build and run
the projects without problems.

Does anybody know any more on this issue?

[Josh Kodroff]

Well, I think I have the problem licked. Basically, you are risking
disaster (i.e. this problem) when you have the same static DLL linked
to 2 projects in the same solution.

So, I checked into MS best practices, and one solution they offer is to
place all the external DLLs for a solution on a network drive, so I
created a dll directory (the DLL's are in SourceSafe, but not in the
projects themselves) and mapped a network drive to that directory.

That way, both Project A and Project B are referencing
ProblemCausingDLL.dll in the same directory: Y:\

Problem solved. This one was particularly infuriating because it won't
occur on one machine (the machine where the Solution was put together),
but will appear on another machine where the person has grabbed the
project from source control.