Running Object Table and .NET

What is the ROT?

“Using ROT (Running Object Table) is a great way to establish interprocess communication between two windows applications. From a purely logical aspect, one application registers a pointer to an instance of a class in the ROT, the other one gets a pointer pointing to the same instance of the registered class and therefore can use the same instance of the class via this pointer. The class that is registered has to be a COM class, otherwise it can be written in any language. The application that will retrieve the pointer from the ROT can be written in any language that can use COM, as ROT gives a pointer to a COM interface.”

Can it be implemented in .NET?

Sure a .NET application can be exposed thru COM and then its pointer can be gotten and consumed by other applications querying the ROT.

And excelent example can be found here: http://www.codeproject.com/KB/COM/ROTStuff.aspx

As always it has its caveats. Be careful.

Obvious replacement?

Well if what you want is (Interprocess Communication) IPC,there are several options in .NET :

* Classical .NET remoting which is very simple and stable to

* Named Pipes see an example here http://bartdesmet.net/blogs/bart/archive/2007/04/12/getting-started-with-named-pipes.aspx

* or WCF with Named Pipes, an example here http://www.codeproject.com/KB/WCF/WCF_CommOptions_part1.aspx

WCF can be an interesting option specially if we were doing things like DCOM and Remote monikers.

ASP Migration COM+ and security

Typical ASP applications were built as a layer of simple ASP with some
COM+ components that did the heavy lifting.

Now, when you migrate your ASP application to ASP.NET and you also migrate your
COM+ components to .NET then you might encounter some issues with security.

One common issue is impersonation.

Sometimes the COM+ were created to use the current user account.

And there is a slight 
difference between ASP and ASP.NET:

“Impersonation is when ASP.NET executes code in the context of an authenticated and authorized client. By default, ASP.NET does not use impersonation and instead executes all code using the same user account as the ASP.NET process, which is typically the ASPNET account. This is contrary to the default behavior of ASP, which uses impersonation by default. In Internet Information Services (IIS) 6, the default identity is the NetworkService account.”

That will cause errors in your ASP.NET application like:

To solve this issue you must use ASP.NET Impersonation, and to enable impersonation go to the web.config file and add:

<identity impersonate=”true”/>

For more info on impersonation see: http://msdn.microsoft.com/en-us/library/aa292118(v=vs.71).aspx

Which App.Config file will my ServiceComponent load?

When a VB6 COM+ Component is migrated to a ServiceComponent,
you might want to take advantage of the Configuration files of .NET to specify your
connection strings and other important information.

So where should your App.Config go.

There is a slight diference with a ServiceComponent.
Remember that for a ServicedComponent the hosting process is ‘dllhost.exe’.
So your programs will look for config files in %windir%\System32, which is not a very nice solution.

You can instead set the ‘Application Base Directory’ of the COM+ Application.

Follow these steps:

1) Create an application.manifest file and copy it to the directory
that will be used as the base directory for the COM+ application. The file can be like:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"/>

2) Create an app.config file and copy that file to the same :

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
<appSettings> 
  <add key="ConfigData" value="My Custom AppSetting!" /> 
</appSettings> 
</configuration>

3) Configure the COM+ Application:

3.1) Open the Component Services MMC

3.2) Find the COM+ Application

3.3) Right Click the Application and go to Properties and Activation Tab

3.4) Find option: ‘Application Root Directory’

3.5) Write the path where the other two files where created.

This blog post was created from an original Blog Post from HeikkiRi.