Assembly reference once removed.

[.pd.]

Hello,

I have a control derived from a 3rd party control. My control sits in a
class library. I have an app referencing my class library. When I
compile the app, I'm told:

c:\pd\NET\Examp les\AssRef\AssR ef\bin\Debug\Mi ne.dll Referenced class
'Mine.Fred' has base class or interface 'Theirs.Flintst one' defined in an
assembly that is not referenced. You must add a reference to assembly
'Theirs'.

Here's some code to reproduce the behaviour:

// main app
using System;
using Mine;

namespace AssRef
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Mine.Fred fred = new Fred();
}
}
}

// my class library
using System;
using Theirs;

namespace Mine
{
public class Fred : Theirs.Flintsto ne
{
public Fred()
{
}
}
}

// 3rd party control

using System;

namespace Theirs
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public class Flintstone
{
public Flintstone()
{
}
}
}

In VS.NET create 2 class libraries and a console app, when you build the
solution, you'll get this:

c:\pd\NET\Examp les\AssRef\AssR ef\bin\Debug\Mi ne.dll Referenced class
'Mine.Fred' has base class or interface 'Theirs.Flintst one' defined in an
assembly that is not referenced. You must add a reference to assembly
'Theirs'.

Why? "Mine" already has an explicit reference to the "Theirs" DLL.

Thanks for any help,

..pd.

[Dmitriy Lapshin [C# / .NET MVP]]

Hello

Your app should also reference the 3rd party control's assembly.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

".pd." <sp*****@your.p eril> wrote in message
news:Xn******** *************** ******@194.83.1 79.102...

Hello,

I have a control derived from a 3rd party control. My control sits in a
class library. I have an app referencing my class library. When I
compile the app, I'm told:

c:\pd\NET\Examp les\AssRef\AssR ef\bin\Debug\Mi ne.dll Referenced class
'Mine.Fred' has base class or interface 'Theirs.Flintst one' defined in an
assembly that is not referenced. You must add a reference to assembly
'Theirs'.

Here's some code to reproduce the behaviour:

// main app
using System;
using Mine;

namespace AssRef
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
Mine.Fred fred = new Fred();
}
}
}

// my class library
using System;
using Theirs;

namespace Mine
{
public class Fred : Theirs.Flintsto ne
{
public Fred()
{
}
}
}

// 3rd party control

using System;

namespace Theirs
{
/// <summary>
/// Summary description for Class1.
/// </summary>
public class Flintstone
{
public Flintstone()
{
}
}
}

In VS.NET create 2 class libraries and a console app, when you build the
solution, you'll get this:

c:\pd\NET\Examp les\AssRef\AssR ef\bin\Debug\Mi ne.dll Referenced class
'Mine.Fred' has base class or interface 'Theirs.Flintst one' defined in an
assembly that is not referenced. You must add a reference to assembly
'Theirs'.

Why? "Mine" already has an explicit reference to the "Theirs" DLL.

Thanks for any help,

.pd.

[Da5id]

Dmitriy Lapshin [C# / .NET MVP] wrote on Fri 19 Dec 2003 02:28:56p:

Your app should also reference the 3rd party control's assembly.

That's what the error message says and is indeed how to fix the problem.
But I don't understand why it *should* be a problem.

What I wanna know is why, when Theirs is not (directly) used by Main,
should Main require a reference to Theirs?

Mine has a reference to Theirs and therefore when control is passed to
Mine, the reference required to reach the referenced code in Theirs is
present.

Why does this stipulation exist? What justification is there for it? If
Mine.DLL was created to use Theirs.DLL, the developer of Mine made the
decision to use version n.n.n of Theirs. Users of Mine shouldn't need to
know that Mine makes calls to other assemblies - but if it should, then
why?

If a developer of Main now has to add a reference to Theirs to get Mine to
work, doesn't that then create a risk that s/he will reference the wrong
version of Theirs? What about transparency?

..pd.

[Erik Frey]

Just because Mine has a reference to Theirs doesn't mean Mine contains
all the implementation and type declarations of Theirs. What if your app
needs to access base members in Flinstone? The app needs a reference to
Theirs so it can cast your Fred class as Flinstone, and execute the get/set
accessors (or whatever else) found in the Theirs assembly.

Erik
"Da5id" <sp*****@your.p eril> wrote in message
news:Xn******** *************** ******@194.83.1 79.102...

Dmitriy Lapshin [C# / .NET MVP] wrote on Fri 19 Dec 2003 02:28:56p:

Your app should also reference the 3rd party control's assembly.

That's what the error message says and is indeed how to fix the problem.
But I don't understand why it *should* be a problem.

What I wanna know is why, when Theirs is not (directly) used by Main,
should Main require a reference to Theirs?

Mine has a reference to Theirs and therefore when control is passed to
Mine, the reference required to reach the referenced code in Theirs is
present.

Why does this stipulation exist? What justification is there for it? If
Mine.DLL was created to use Theirs.DLL, the developer of Mine made the
decision to use version n.n.n of Theirs. Users of Mine shouldn't need to
know that Mine makes calls to other assemblies - but if it should, then
why?

If a developer of Main now has to add a reference to Theirs to get Mine to
work, doesn't that then create a risk that s/he will reference the wrong
version of Theirs? What about transparency?

.pd.

[Grant Richins [MS]]

Well, since C# has no notion of private inheritance like C++, all base
classes contribute methods, properties, etc. to your class. Thus the
compiler needs to see all metadata for the base types. Now if you used
containment rather than inheritance, that would be different. Then you
could successfully structure your assembly so that no clients would ever
need to directly reference your dependencies.

--
--Grant
This posting is provided "AS IS" with no warranties, and confers no rights.
"Da5id" <sp*****@your.p eril> wrote in message
news:Xn******** *************** ******@194.83.1 79.102...

Dmitriy Lapshin [C# / .NET MVP] wrote on Fri 19 Dec 2003 02:28:56p:

Your app should also reference the 3rd party control's assembly.

That's what the error message says and is indeed how to fix the problem.
But I don't understand why it *should* be a problem.

What I wanna know is why, when Theirs is not (directly) used by Main,
should Main require a reference to Theirs?

Mine has a reference to Theirs and therefore when control is passed to
Mine, the reference required to reach the referenced code in Theirs is
present.

Why does this stipulation exist? What justification is there for it? If
Mine.DLL was created to use Theirs.DLL, the developer of Mine made the
decision to use version n.n.n of Theirs. Users of Mine shouldn't need to
know that Mine makes calls to other assemblies - but if it should, then
why?

If a developer of Main now has to add a reference to Theirs to get Mine to
work, doesn't that then create a risk that s/he will reference the wrong
version of Theirs? What about transparency?

.pd.