Problem with interop .NET dlls in distributed client applications

[SPanicker]

Hi,

I have a .NET DLL (exposed for COM interop) migrated from a server into many client machines. This DLL is causing an Automation error 0x80070002 ("The system cannot find the file specified. ").

The invoking VB dll is in the same folder as the .NET dll and is having a proper .tlb refernce made which is visible in Intellisense.

I am quite confused why this error should popup as everything is fine with both the components. Even re-registering the component with regasm didn't help.

But the interesting thing is that, it started working when I locally compiled the .NET component(using .NET 2005).

Why does this happen? I cannot make out anything as both the binaries I have (the migrated ones and the locally compiled ones) are identical.

Can anyone please provide an insight ?


Regards,
SP.

[SPanicker]

Can somebody share thoughts on this?

[SPanicker]

This problem still persists. Any knowledge sharing on this?

[vekipeki]

After using regasm, you should register your assembly in GAC (using gactool). Note that, once your assembly is in GAC, changes to your local assembly copy will not reflect in GAC, so be careful to register it in GAC every time you're updating your dlls.

If you don't want to use GAC, just use the /codebase option with regasm, that way you can specify a custom folder for your assembly.

Read this article for more info: http://msdn.microsoft.com/en-us/libr...w6(VS.71).aspx

[SPanicker]

Thanx for the post.
The problem is with the dll migrated from a build machine and not with registering/GAC-ing. It seems the dll built and copied from the build machine due to some reason cannot be recognized in the client machine. I tried re-registering the comp. from the build machine in the client using /codebase switch but it doesn't workout.

[vekipeki]

But didn't you say they were identical (I presume you diff-ed them to make sure)? If they are binary identical, then it's impossible to replace one binary file with another (exactly the same), and have different results, it just doesn't make sense. Except if there's something different with their Read&Execute permissions or something like that?

Are you sure that compiling the assembly locally didn't register it in GAC? You compiled it and then replaced the old assembly with the new one?

[SPanicker]

No actually I am not trying to put it in GAC and I don't have given a strong name either for the .dll.
Yes the binaries are identical (the one built in build machine and copied to client and the one locally compiled) - that is what is driving me crazy.

Is there any tool (from MS) to check for the similarity of .NET binaries created?

Also one more aspect to note is that, the class has a progid set but I am not using it anywhere - can this be removed?
And also the constructor of my .NET class instantiates classes which creates instances of unmanaged code / COM components.

Any thoughts?

[vekipeki]

Is there any tool (from MS) to check for the similarity of .NET binaries created?

If they are identical, they are identical, regardless of the tool used. How did you find out they are identical in the first place?

You can use any diff tool you like (File comparison tools).

Also one more aspect to note is that, the class has a progid set but I am not using it anywhere - can this be removed?

You don't need to remove the progid. Try to open regedit and search for your COM GUID. You should be able to find a node named InprocServer32, which will contain the path to the used assembly (CodeBase) - since you are not using GAC, you have to use the /codebase switch. Check if that path is correct.

[SPanicker]

Sory the DLLs are binarily diff. but the tlbs are identical. I used Winmerge to check this.

Yes it has the proper path set in 'InProcServer/Codebase' key.

I found that the CLSIDs are different by case (one that mentioned in dll and the one in registry) - is that a problem?

Also the Interface GUID doesn't have any reference to CLSIDs - is that necessary?

[SPanicker]

veki any thoughts on this?