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.

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