Oddity with 'protected internal' and derivation

[Clive Dixon]

I am refactoring some code to move some base classes into a separate
assembly. One of these base classes has a member property which is
'protected internal'. However when I move these base classes to another
assembly, the compiler complains that the override in the derived class,
also declared as 'protected internal', is trying to change the access
modified from 'protected', which is clearly not the case. (I have checked
the metadata in the assembly and the base class property is 'famorassem'.)
If I change the derived class declaration to just 'protected', it works OK.
Anybody have an explanation as to why it is working this way?

[Serge Baltic]

Hello,

>>Which would mean a circular reference of assemblies.

Which is just OK with .NET, why not?

I don't believe so - as far as I'm aware, if assembly A references
assembly B, the reverse can't be true.

Easily. I've just written a couple such assemblies:

w:\Circular>a1. exe
Created
I'm A1.C1, A1, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null. I have
a field A2.C2.
I'm A2.C2, A2, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null. I have
a field A1.C1.
Done

You don't have to take my word for it, you can just check the references
list of System.dll and System.Xml.dll :) Surprisingly, they're circularly-referenced
as well.

For one thing, you've got a problem as to which you compile first...

To reference an assembly at compile-time, all you need is the assembly name,
version, culture, and public key token. All of them are known even before
the assembly is compiled.

You can have circular *class* references, but they need to be in the
same assembly.

No, they needn't. Those C1 and C2 classes of mine each have a field of the
other's type. That compiles, passes peverify.exe, loads, and runs.

It's true that you cannot do circular references in C#, which is mostly because
C# wants to validate everything at compile time, and you cannot verify much
until all the referenced assemblies exist. So it's a bit offtopic in a .csharp
newsgroup, but still possible in the real world ;)

(H) Serge

[Jon Skeet [C# MVP]]

(I started replying before reading the whole thing - I've left my
comments in rather than taking them all out, in order to explain my
reactions.)

Serge Baltic <ba*****@hypers w.netwrote:

>Which would mean a circular reference of assemblies.
Which is just OK with .NET, why not?

I don't believe so - as far as I'm aware, if assembly A references
assembly B, the reverse can't be true.

Easily. I've just written a couple such assemblies:

w:\Circular>a1. exe
Created
I'm A1.C1, A1, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null. I have
a field A2.C2.
I'm A2.C2, A2, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null. I have
a field A1.C1.
Done

How did you compile those then?

You don't have to take my word for it, you can just check the references
list of System.dll and System.Xml.dll :) Surprisingly, they're circularly-referenced
as well.

Indeed, you're right. I'm frankly confused.

For one thing, you've got a problem as to which you compile first...

To reference an assembly at compile-time, all you need is the assembly name,
version, culture, and public key token. All of them are known even before
the assembly is compiled.

But if you add a reference to an assembly, it will check whether or not
that exists, won't it? Otherwise how can it ensure that the type you're
referencing exists?

You can have circular *class* references, but they need to be in the
same assembly.

No, they needn't. Those C1 and C2 classes of mine each have a field of the
other's type. That compiles, passes peverify.exe, loads, and runs.

It's true that you cannot do circular references in C#, which is
mostly because C# wants to validate everything at compile time, and
you cannot verify much until all the referenced assemblies exist. So
it's a bit offtopic in a .csharp newsgroup, but still possible in the
real world ;)

Ah, I see. It all makes sense now - you're not using the C# compiler.
That certainly changes things. Your comment of "Which is just OK with
..NET, why not?" (referring to circular assembly references) implies
that there's no problem with circular references. Not being able to
compile such a situation in C# is certainly a problem for most of us :)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Serge Baltic]

Hello,

Ah, I see. It all makes sense now - you're not using the C# compiler.
That certainly changes things. Your comment of "Which is just OK with
.NET, why not?" (referring to circular assembly references) implies
that there's no problem with circular references. Not being able to
compile such a situation in C# is certainly a problem for most of us
:)

Uh … well … I'm sorry, but of course you can write them in C# :) I've rewritten
my example in .cs, and here're two valid circularly-referencing C#-compiled
assemblies:

w:\Circular\01> a1.exe
I'm "A1.C1, A1, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null". I
can see "A2.C2, A2, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null".
I'm "A2.C2, A2, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null". I
can see "A1.C1, A1, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null".

Using just two .cs files and a few csc.exe calls to compile them. Easy fun.
:)

(H) Serge

[Jon Skeet [C# MVP]]

Serge Baltic <ba*****@hypers w.netwrote:

Ah, I see. It all makes sense now - you're not using the C# compiler.
That certainly changes things. Your comment of "Which is just OK with
.NET, why not?" (referring to circular assembly references) implies
that there's no problem with circular references. Not being able to
compile such a situation in C# is certainly a problem for most of us
:)

Uh ? well ? I'm sorry, but of course you can write them in C# :) I've rewritten
my example in .cs, and here're two valid circularly-referencing C#-compiled
assemblies:

w:\Circular\01> a1.exe
I'm "A1.C1, A1, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null". I
can see "A2.C2, A2, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null".
I'm "A2.C2, A2, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null". I
can see "A1.C1, A1, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null".

Using just two .cs files and a few csc.exe calls to compile them. Easy fun.
:)

So how did you compile them? I can see how you could compile one
version of assembly A which *didn't* refer to B, then compile B
referring to A, then recompile A referring to B. Hardly the kind of
thing you'd want to do on a regular basis though, is it? In particular,
I suspect you wouldn't be able to do it within Visual Studio, although
admittedly I haven't tried.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too