2.0+ Events Handled by 1.x Subscribers

[Robert Cramer]

Given that Generics are available only in .NET 2.0+ and not in 1.x....

If a .NET 2.0+ event publisher were to make use of System.EventHandler<T>,
or otherwise make use of Generics, in its event implementation, would that
preclude a .NET 1.x app from subscribing to and handling that event?

Thanks!

 

[Marc Gravell]

Yes. In fact, you'll have a hard time referencing the assembly at all.

Marc

 

[Robert Cramer]

Yes. In fact, you'll have a hard time referencing the assembly at all.

Marc

What if I want to write an event publishing component in .NET 2.0, but I
need to make the event available to .NET 1.x applications. Can I write my
component in 2.0 and simply avoid any use of Generics? Would that be good
enough to enable 1.x apps to subscribe to my events implemented in a 2.0
component (library)?

Thanks.

 

[Jon Skeet [C# MVP]]

What if I want to write an event publishing component in .NET 2.0, but I
need to make the event available to .NET 1.x applications. Can I write my
component in 2.0 and simply avoid any use of Generics? Would that be good
enough to enable 1.x apps to subscribe to my events implemented in a 2.0
component (library)?

No. If you build your component in .NET 2.0, you won't be able to
reference it from a .NET 1.1 application, whether you use any new
features or not.

 

[Robert Cramer]

No. If you build your component in .NET 2.0, you won't be able to
reference it from a .NET 1.1 application, whether you use any new
features or not.

Okay. Now, for the sake of my curiosity, what about the other way around.
Can I reference a 1.1 .NET component from a 2.0 app and subscribe to events
(published by a 1.1 component)? I would think so because of backwards
compatability...

Thanks.

 

[Marc Gravell]

There are IL differences between 1.1 and 2.0; 2.0 has new op-codes
that simply cannot be executed under 1.1; as such, (AFAIK) it simply
won't load the assembly under the 1.1 runtime. So if you want your app
to work on a machine that only has the 1.1 runtime, then you cannot do
this.

Likewise, the 1.1 compiler won't (AFAIK) be happy to reference a 2.0
assembly when building a 1.1 assembly.

If you have a 2.0 application that *happens* to include a reference to
a 1.1 assembly, and that 1.1 assembly is somehow (at runtime, not
compile-time) given an untyped (object) reference to an object from a
2.0 assembly, and it then uses reflection or System.ComponentModel to
access the object instance, then it *might* just get away with it. But
I wouldn't like to be the one to support it ;-p

In many (not all) ways, 1.1 is largely obsolete. I know there is still
a drive to support it to reduce the system requirements; and likewise
it is closer to what Mono can reliably deliver if you want
compatibility, but... in fact, mainstream support for 1.1 is only for
another year (14 Oct 2008, according to MS software roadmap dated Aug
2007)

Personally, I'd look to be making the switch to 2.0 - but I understand
there are often business reasons to stick with 1.1; but the majority
of .NET developers are either using VS2005 or the VS2008 previews -
neither of which natively supports developing 1.1 (unless you count
the MSBee extensions).

Marc

 

[Marc Gravell]

Yes; 2.0 includes all of the 1.1 op-codes, so 2.0 is perfectly happy
to work with a 1.1 assembly. I don't think MS could reasonably have
done otherwise, as the migration cost (waiting for 2.0 upgrades of
3rd-party components) would be too great.

Marc

 

[Jon Skeet [C# MVP]]

Personally, I'd look to be making the switch to 2.0 - but I understand
there are often business reasons to stick with 1.1; but the majority
of .NET developers are either using VS2005 or the VS2008 previews -
neither of which natively supports developing 1.1 (unless you count
the MSBee extensions).

My feeling (based on limited experience, and what others have been
saying) is that most developers are using 2.0+ for green-field code and
1.1 for maintenance to existing code bases. In addition, I think many
companies are gradually upgrading their code bases to 2.0. However, I
suspect it'll be a while before most companies can say that *all* their
projects are VS2005 projects etc.