New to distributed components: query

[Ian]

I am working with Distributed Components with VB.NET for the first time
(pretty much), and am having the following problem. My components have been
added and are visible in component services manager. They have also been
added to the GAC.

On seeking to set a reference to these components on the COM tag of the Add
Referrence dialog, I get the following error message:

"A reference to <component name> could not be added. Converting the type
library to a .NET assembly failed. Type library <component name> was exported
from a CLR assembly and cannot be re-imported as a CLR assembly."

The components show up on the COM components tag, but not on the .NET
components tag, of the Add Reference dialog, so I dont see how I can get
round this. Any advice as to what I am doing wrong?

Thanks

Ian

[David Browne]

"Ian" <ia********@NOS PAM.aol.com> wrote in message
news:C3******** *************** ***********@mic rosoft.com...

I am working with Distributed Components with VB.NET for the first time
(pretty much), and am having the following problem. My components have
been
added and are visible in component services manager. They have also been
added to the GAC.

On seeking to set a reference to these components on the COM tag of the
Add
Referrence dialog, I get the following error message:

"A reference to <component name> could not be added. Converting the type
library to a .NET assembly failed. Type library <component name> was
exported
from a CLR assembly and cannot be re-imported as a CLR assembly."

The components show up on the COM components tag, but not on the .NET
components tag, of the Add Reference dialog, so I dont see how I can get
round this. Any advice as to what I am doing wrong?

You definitely need add the reference through the .NET components tab. If
you don't see them in the list, just navigate to them on disk.

David

[Ian]

"David Browne" wrote:

You definitely need add the reference through the .NET components tab. If
you don't see them in the list, just navigate to them on disk.

Thanks. However, there is something else I am puzzled about. I am trying to
implement transaction processing using VB.NET running on Windows 2000, though
the transaction I am using is fairly noddy at the moment, just by way of
exploration. The original question I raised was the by-product of another
problem, which is as follows:

The transaction I am using involves one server component that initiates a
transaction (using the Transaction(Tra nsactionOption. RequiresNew) attribute
setting). This component does not actually do anything, except call two
further components that add records to two different tables respectively an
in MSDE 2000 Database. Each of these secondary components has its Transaction
attribute set to TransactionOpti on.Supported.

The primary component has its references to the two secondary components set
using the .NET tab in the References dialog, as you said. Directly pointing
to the DLL's files in the <project>/bin directory on the development machine
(at this stage I do not have access to a separate server). I have a
straightforward Windows Application client that calls the primary component
in this way, which in turn calls the two secondary components. And the
transaction appears to work fine.

HOWEVER: the point of this exercise was to demonstrate the principle of
transaction processing. And part of that was to illustrate what happens when
a transaction fails. And the way to make it fail was to delete one of the
secondary components from the Component Services manager. That is supposed to
trigger an error in the transaction, and thus cause the transaction to not
complete, and indeed to roll back the work of the other secondary transaction
component.

The only problem is that the transaction doesnt fail. It still runs
perfectly even though the COM+ reference has been removed from Component
Services. I have even physically deleted the .tlb file, and run the
transaction again, and still it completes perfectly. This should not happen,
and makes me think that in some way COM+ is being bypassed. Yet things like
object pooling etc in COM+ services seem to work fine.

Any idea why my transaction is refusing to fail in these circumstances?

[David Browne]

"Ian" <ia********@NOS PAM.aol.com> wrote in message
news:A7******** *************** ***********@mic rosoft.com...

"David Browne" wrote:

You definitely need add the reference through the .NET components tab.
If
you don't see them in the list, just navigate to them on disk.

Thanks. However, there is something else I am puzzled about. I am trying
to
implement transaction processing using VB.NET running on Windows 2000,
though
the transaction I am using is fairly noddy at the moment, just by way of
exploration. The original question I raised was the by-product of another
problem, which is as follows:

The transaction I am using involves one server component that initiates a
transaction (using the Transaction(Tra nsactionOption. RequiresNew)
attribute
setting). This component does not actually do anything, except call two
further components that add records to two different tables respectively
an
in MSDE 2000 Database. Each of these secondary components has its
Transaction
attribute set to TransactionOpti on.Supported.

The primary component has its references to the two secondary components
set
using the .NET tab in the References dialog, as you said. Directly
pointing
to the DLL's files in the <project>/bin directory on the development
machine
(at this stage I do not have access to a separate server). I have a
straightforward Windows Application client that calls the primary
component
in this way, which in turn calls the two secondary components. And the
transaction appears to work fine.

HOWEVER: the point of this exercise was to demonstrate the principle of
transaction processing. And part of that was to illustrate what happens
when
a transaction fails. And the way to make it fail was to delete one of the
secondary components from the Component Services manager. That is supposed
to
trigger an error in the transaction, and thus cause the transaction to not
complete, and indeed to roll back the work of the other secondary
transaction
component.

The only problem is that the transaction doesnt fail. It still runs
perfectly even though the COM+ reference has been removed from Component
Services. I have even physically deleted the .tlb file, and run the
transaction again, and still it completes perfectly. This should not
happen,
and makes me think that in some way COM+ is being bypassed. Yet things
like
object pooling etc in COM+ services seem to work fine.

Any idea why my transaction is refusing to fail in these circumstances?

Yes. Once you make the transition from COM to .NET, you don't go back
through COM+ to access other .NET components. This is exactly the same
reason why you couldn't add a COM reference to your other .NET component.
When one .NET object creates another .NET object is simply doen't call
CoCreateObject( ). It all happens inside .NET.

You could make your transaction fail by violating a CHECK constraint in the
database or something like that...

David