Problems with deploying .Net App to be used by COM application

The DLL and TLB have both been put onto the Server correctly. I have checked the registry and this also seems to have been updated correctly.

I have admin rights on the server when I'm trying to deploy.

If you are using a terminal server to install/test:
http://support.microsoft.com/default.aspx?kbid=823485

I am using Terminal Server to test the deployment and it is W2K SP2. However I don't think that KB article covers my scenario as the user I log on as has admin rights.

I have also tested a simple .Net exe and can instantiate my object from this .Net test harness.
My assumption still is that there is something wrong with the way I have deployed my component to be called by COM.

Is your .NET assembly in the GAC ?

gacutil -i <yourassembly.dll>

Vasco

Gave this a try and I get Assembly must have a strong name message.

I've had a quick flick thru MSDN and I'm trying to sign my assembly by adding the AssemblyKeyFile attribute to AssemblyInfo.vb.

This doesn't like the reference to MSXML2 I have in my project. I get the following message when I build:
Unable to emit Assembly: Referenced assembly 'Interop.MSXML2' does not have a strong name

Is there a way around this ? Do you think that putting it in the GAC is the only way to get it working ?

Put it in the GAC, and checked this through the .Net Framework configuration tool.

I still have the same issue though.

puting it in the GAC makes sure that it gets found from any location your code might be executing.

Do you have the MSXML installed on the target machines ? if that's something you're making use of, than make sure it's registered.
(why are you not using System.Xml... MSXML in .NET is not recommended: 815112 - INFO: Use of MSXML is Not Supported in .NET Applications - http://support.microsoft.com/default.aspx?scid=kb;EN-US;815112)

My suggestion would be for you to take small steps:
create a very basic assembly and start by making sure it's executing fine (can be called from a .NET app)
then, register it for interop and put it in the GAC
test again...

The MSXML reference was a hang over from a quick upgrade of code. I removed this in order to strong name the assembly.

I see where you're coming from on the small steps. The ones I have taken so far is to produce a much simpler test assembly that exhibits the same behaviour, (Automation Error File Not found). I have also deployed a .Net exe that shows the component I want to deploy can be instantiated from managed code.

Is the GAC used if I am calling a .Net component from COM I thought it would just go by the registry entry created.

The file not found error, really appears to show that it cannot find the assembly that implements the type.
Do you have it in the GAC.

try this:
// start MyLib.cs
using System;
using System.Reflection;

[ assembly: AssemblyKeyFile( "MyLib.snk" ) ]

[ ProgId( "MyCompany.MyProject.MyClass" ) ]
class MyClass
{
  public DateTime CurrentTime()
  {
    return DateTime.Now;
  }
}
// end

// to compile
sn -k MyLib.snk
csc /debug+ MyLib.cs

regasm /tlb MyLib.dll
gacutil -i MyLib.dll

By now, you should have the assembly in the GAC and the correct registry entries for COM

Now, in a vbs script you can do:

Set o = CreateObject( "MyCompany.MyProject.MyClass" );
wscript.echo o.CurrentTime


Does this work ?

I haven't had a chance to try the code above, I'll get to it soon.

I have tested creating and calling my component from a simple vbs file. From here I can create my component and call a method on it succesfully. I'm testing this logged on as admin.

However when a user logs to the Terminal Server box and tries to do the same from a VBA macro then they still get an error.

I have added Windows auditing to the folders containing my component but this doesn't show any access (success or failure) from this user. So I still don't think the object is getting created.

Hi Delc,

how is this going ?

not sure which version of win you're using, but either make the registry changes locally, or using mstsc.exe /console (to log into the terminal console).

hth,

Vasco

Hi vascov

Thanks for sticking with me on this. I am still working through the problem.
Following on from the last comment I have been testing my component from a simple vbs.

This gives the following results accessing the TS box as Admin user my component works.
Accessing the TS box as with no Admin privileges my component cannot be created and the error is still file not found.

This seems to me to be a permissions issue where the admin user has access to some files that a normal user doesn't. I intend to try and trace this by adding auditing to trace which files can't be accessed. I am not sure where I should be looking though is the problem likely to be with my component or with .Net framework files or somewhere else ?

Hi DelC,

If you can, do the registration and setup of the component "interactively" on the computer, and not via Terminal Services.

What might be happening is that the changes you performed are being registered only for the Admin user (which was the one doing setup).

Just in case it's really a permission issue, use filemon from sysinternals, to have a look at the file requests and their outcomes.
Another thing you can do is to use fuslogvw (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfFusionLogViewerFuslogvwexe.asp), which is a .NET tool that will show you the details of the attempt to load the assembly.

let me know how this goes

Vasco

Hi Vasco

Finally got to an answer. With auditing turned on the following entry came up in the security log: Privilege Use (577) Privileges: SeCreateGlobalObjects.

I did a search on MSDN and came up with the following article (http://support.microsoft.com/default.aspx?kbid=821546). Following the instructions about giving the "Create Global Objects" user right to the required user group allows me to instantiate my component !

Thanks for your help.
I will post a request to close this question but would still like to award you some points for your support.

DelC

Kool.

Glad that you've found it, and even more for sharing the solution.

Vasco