Mutliple entry points

[Anonymous]

Was there any thought given to supporting multiple
IExtensionApplication implementations in a single
assembly, the interop?

I can clearly see good reasons why I would want to
have them. If I take code and put it in a separate
assembly that is referenced from another, each can
get control when it is loaded, by way of the fact that
AutoCAD processes assemblies from the AppDomain's
OnAssemblyLoad() handler, and treats the primary
and referenced assemblies with indifference, so each
can have its own IExtensionApplication implementation
that gets called on load/unload.

But, if I move code from several assemblies into a
single one, I have to make changes, because there
can be only a single entry point for each assembly.

I don't think I like that at all.

You might want to be wary of this, given that there
is a tool from MS that allows you to combine multiple
assemblies into a single one, and I would imagine that
given several assemblies with an implementation of IExtensionApplication, something will break if you were
to merge them into a single assembly.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

[Anonymous]

Frankly, I haven't thought about this. What do these assembly combining
tools do about module constructors? These are new to .net 2.0 and get called
when a module is loaded. If module constructors were available in .net 1.1
we wouldn't have the IExtensionApplication stuff at all.

Albert

"Tony Tanzillo" wrote in message
news:4948711@discussion.autodesk.com...
Was there any thought given to supporting multiple
IExtensionApplication implementations in a single
assembly, the interop?

I can clearly see good reasons why I would want to
have them. If I take code and put it in a separate
assembly that is referenced from another, each can
get control when it is loaded, by way of the fact that
AutoCAD processes assemblies from the AppDomain's
OnAssemblyLoad() handler, and treats the primary
and referenced assemblies with indifference, so each
can have its own IExtensionApplication implementation
that gets called on load/unload.

But, if I move code from several assemblies into a
single one, I have to make changes, because there
can be only a single entry point for each assembly.

I don't think I like that at all.

You might want to be wary of this, given that there
is a tool from MS that allows you to combine multiple
assemblies into a single one, and I would imagine that
given several assemblies with an implementation of IExtensionApplication,
something will break if you were
to merge them into a single assembly.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

[Anonymous]

Hi Albert.

I'm not sure I understand how module constructors would
address the issue, given that they are supported only at
the CLR level, but not at the CLI level (e.g., I can't write
one in C#, or am I mistaken about that?).

Regarding IExtensionApplication. Sorry if this seems like
20/20 hindsight, but my opinion is that you should either
support multiple implementations of that interface, or
any case where an assembly is found to contain multiple
implementations, should be treated as an error.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message news:4948798@discussion.autodesk.com...
Frankly, I haven't thought about this. What do these assembly combining
tools do about module constructors? These are new to .net 2.0 and get called
when a module is loaded. If module constructors were available in .net 1.1
we wouldn't have the IExtensionApplication stuff at all.

Albert

"Tony Tanzillo" wrote in message
news:4948711@discussion.autodesk.com...
Was there any thought given to supporting multiple
IExtensionApplication implementations in a single
assembly, the interop?

I can clearly see good reasons why I would want to
have them. If I take code and put it in a separate
assembly that is referenced from another, each can
get control when it is loaded, by way of the fact that
AutoCAD processes assemblies from the AppDomain's
OnAssemblyLoad() handler, and treats the primary
and referenced assemblies with indifference, so each
can have its own IExtensionApplication implementation
that gets called on load/unload.

But, if I move code from several assemblies into a
single one, I have to make changes, because there
can be only a single entry point for each assembly.

I don't think I like that at all.

You might want to be wary of this, given that there
is a tool from MS that allows you to combine multiple
assemblies into a single one, and I would imagine that
given several assemblies with an implementation of IExtensionApplication,
something will break if you were
to merge them into a single assembly.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

[Anonymous]

I was curious about module constructors because they have a similar
semantics to IExtensionApplication so if I wanted to know how those are
handled by these combining tools. You are right you can't do module
constructors in C#. I didn't realize that.

I don't think we are going to change the semantics of IExtensionApplication.
The contract has been that we call one. If you have more than one then it is
underfined which one we are going to call. Tightening the contract would
penalize all assemblies (we would have to scan all public types) for the
benefit of a few.

Albert

"Tony Tanzillo" wrote in message
news:4949519@discussion.autodesk.com...
Hi Albert.

I'm not sure I understand how module constructors would
address the issue, given that they are supported only at
the CLR level, but not at the CLI level (e.g., I can't write
one in C#, or am I mistaken about that?).

Regarding IExtensionApplication. Sorry if this seems like
20/20 hindsight, but my opinion is that you should either
support multiple implementations of that interface, or
any case where an assembly is found to contain multiple
implementations, should be treated as an error.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message
news:4948798@discussion.autodesk.com...
Frankly, I haven't thought about this. What do these assembly combining
tools do about module constructors? These are new to .net 2.0 and get called
when a module is loaded. If module constructors were available in .net 1.1
we wouldn't have the IExtensionApplication stuff at all.

Albert

"Tony Tanzillo" wrote in message
news:4948711@discussion.autodesk.com...
Was there any thought given to supporting multiple
IExtensionApplication implementations in a single
assembly, the interop?

I can clearly see good reasons why I would want to
have them. If I take code and put it in a separate
assembly that is referenced from another, each can
get control when it is loaded, by way of the fact that
AutoCAD processes assemblies from the AppDomain's
OnAssemblyLoad() handler, and treats the primary
and referenced assemblies with indifference, so each
can have its own IExtensionApplication implementation
that gets called on load/unload.

But, if I move code from several assemblies into a
single one, I have to make changes, because there
can be only a single entry point for each assembly.

I don't think I like that at all.

You might want to be wary of this, given that there
is a tool from MS that allows you to combine multiple
assemblies into a single one, and I would imagine that
given several assemblies with an implementation of IExtensionApplication,
something will break if you were
to merge them into a single assembly.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

[Anonymous]

Hi Albert. Like said, this is 20/20 hindsight, but I
consider having multiple implementations of the
interface in the same assembly without declaring
IExtensionApplicationAttribute, an error.

The problem with the design is that it flies in the
face of code modularity and resusablity. The fact
that because of it, adding or removing a module
to/from a project can have adverse affects on any
other modules in the project, just stinks 🙂

I wouldn't even bother with scanning every type for
the interface. I would have just supported it via
the assembly level IExtensionApplicationAttrribute,
and that's all, because that makes it explicit, and
eliminates the possiblity that the programmer has
multiple implementations of the interface, without
realizing it.

As far as supporting multiple implementations of
IExtensionApplication, I agree that doing that by
scanning all types is certainly expensive, and so,
why bother doing that at all?

It could be done with no cost, by just allowing
multiple IExtensionApplicationAttribute's at the
assembly level, and processing each of them.

Since you are already avoiding a scan of all types
when one of these is found, it would seem to me,
that allowing and processing multiple instances
of this attribute wouldn't break anything.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message news:4949566@discussion.autodesk.com...
I was curious about module constructors because they have a similar
semantics to IExtensionApplication so if I wanted to know how those are
handled by these combining tools. You are right you can't do module
constructors in C#. I didn't realize that.

I don't think we are going to change the semantics of IExtensionApplication.
The contract has been that we call one. If you have more than one then it is
underfined which one we are going to call. Tightening the contract would
penalize all assemblies (we would have to scan all public types) for the
benefit of a few.

Albert

[Anonymous]

On further reflection, I concede that IExtensionApplication should
be a singleton because its purpose goes beyond simply listening
for Initialize() and Terminate(), so perhaps I'm confusing the main
purpose of it (sort of like CWinApp), with a simpler need that it
fulfills, which is to get control when the containing assmbly loads.

Hopefully, you will see the problem and need associated with
IExtensionApplication collisions, and perhaps offer an alternative
means of getting notifications.

For now, I implement a single IExtensionApplication with the
assembly attribute, and from its implementation, I drive a
secondary mechansim that looks like this:

[assembly: OnLoad(typeof(MyNamespace.Class1))]
[assembly: OnLoad(typeof(MyNamespace.Class2))]

namespace MyNamespace
{
public class Class1
{
public static Class1() // static c'tor
{
// Some initialization code here.
}
}

public class Class2
{
public static Class1()
{
// more initialization code here.
}
}
}

Of course the problem remains, that I have to use
IExtensionApplication to drive all of this.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message news:4949566@discussion.autodesk.com...
I was curious about module constructors because they have a similar
semantics to IExtensionApplication so if I wanted to know how those are
handled by these combining tools. You are right you can't do module
constructors in C#. I didn't realize that.

I don't think we are going to change the semantics of IExtensionApplication.
The contract has been that we call one. If you have more than one then it is
underfined which one we are going to call. Tightening the contract would
penalize all assemblies (we would have to scan all public types) for the
benefit of a few.

Albert

[Anonymous]

Ok. I see what you want. I think this falls outside, the intentionally
loose, contract autocad has with addins. Add-ins are assemblies. We don't
support multiple "extension aplications" in the same assembly.

IExtensionApplication was intended to be an acrxEntryPoint-like thing. Even
if we enforce uniqueness you wouldn't be helped much.
I think you want to establish your own pattern. What you are doing looks
good although it feels a bit obscure. I would probably use a global App
class (implementing IExtensionApplication) that exposes a "Loaded" event
instead.

Albert

"Tony Tanzillo" wrote in message
news:4949654@discussion.autodesk.com...
On further reflection, I concede that IExtensionApplication should
be a singleton because its purpose goes beyond simply listening
for Initialize() and Terminate(), so perhaps I'm confusing the main
purpose of it (sort of like CWinApp), with a simpler need that it
fulfills, which is to get control when the containing assmbly loads.

Hopefully, you will see the problem and need associated with
IExtensionApplication collisions, and perhaps offer an alternative
means of getting notifications.

For now, I implement a single IExtensionApplication with the
assembly attribute, and from its implementation, I drive a
secondary mechansim that looks like this:

[assembly: OnLoad(typeof(MyNamespace.Class1))]
[assembly: OnLoad(typeof(MyNamespace.Class2))]

namespace MyNamespace
{
public class Class1
{
public static Class1() // static c'tor
{
// Some initialization code here.
}
}

public class Class2
{
public static Class1()
{
// more initialization code here.
}
}
}

Of course the problem remains, that I have to use
IExtensionApplication to drive all of this.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message
news:4949566@discussion.autodesk.com...
I was curious about module constructors because they have a similar
semantics to IExtensionApplication so if I wanted to know how those are
handled by these combining tools. You are right you can't do module
constructors in C#. I didn't realize that.

I don't think we are going to change the semantics of IExtensionApplication.
The contract has been that we call one. If you have more than one then it is
underfined which one we are going to call. Tightening the contract would
penalize all assemblies (we would have to scan all public types) for the
benefit of a few.

Albert

[Anonymous]

Hi Albert. Thanks.

Event handlers are unusable in this context, because we
must execute code to add the event handler. 🙂


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message news:4949868@discussion.autodesk.com...
Ok. I see what you want. I think this falls outside, the intentionally
loose, contract autocad has with addins. Add-ins are assemblies. We don't
support multiple "extension aplications" in the same assembly.

IExtensionApplication was intended to be an acrxEntryPoint-like thing. Even
if we enforce uniqueness you wouldn't be helped much.
I think you want to establish your own pattern. What you are doing looks
good although it feels a bit obscure. I would probably use a global App
class (implementing IExtensionApplication) that exposes a "Loaded" event
instead.

Albert

"Tony Tanzillo" wrote in message
news:4949654@discussion.autodesk.com...
On further reflection, I concede that IExtensionApplication should
be a singleton because its purpose goes beyond simply listening
for Initialize() and Terminate(), so perhaps I'm confusing the main
purpose of it (sort of like CWinApp), with a simpler need that it
fulfills, which is to get control when the containing assmbly loads.

Hopefully, you will see the problem and need associated with
IExtensionApplication collisions, and perhaps offer an alternative
means of getting notifications.

For now, I implement a single IExtensionApplication with the
assembly attribute, and from its implementation, I drive a
secondary mechansim that looks like this:

[assembly: OnLoad(typeof(MyNamespace.Class1))]
[assembly: OnLoad(typeof(MyNamespace.Class2))]

namespace MyNamespace
{
public class Class1
{
public static Class1() // static c'tor
{
// Some initialization code here.
}
}

public class Class2
{
public static Class1()
{
// more initialization code here.
}
}
}

Of course the problem remains, that I have to use
IExtensionApplication to drive all of this.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message
news:4949566@discussion.autodesk.com...
I was curious about module constructors because they have a similar
semantics to IExtensionApplication so if I wanted to know how those are
handled by these combining tools. You are right you can't do module
constructors in C#. I didn't realize that.

I don't think we are going to change the semantics of IExtensionApplication.
The contract has been that we call one. If you have more than one then it is
underfined which one we are going to call. Tightening the contract would
penalize all assemblies (we would have to scan all public types) for the
benefit of a few.

Albert