Hi, I am having the same problem and still couldn't resolve it yet.

Which version of Wise?

This could be caused by a bug in Wise that adds .NET assembly files to the hash table. Click Properties on the file and uncheck Add to Hash table.

I remember that some older version of Wise that had this same trouble with .NET 1.1 vs 2.0. If I remeber correctly I had to run a Repair for the Wise installation. It could have something do with in which order Wise and .NET frameworks are installed.

There should be some knowledgebase articles about this.

Installation Studio 7.3.0.250.

Does anyone know what is used for Registry scanning?  Is it some behind the scenes magic using RegAsm with the /regfile option to create a .reg file that is then sucked into the template (registry table)?

If this is the case, this will not include the type library interface information. Therefore, boom!

I don't know how the scanning works. Did you check if the file has been added to the hash table? It should not.

Read this: https://kb.altiris.com/article.asp?article=34373&p=1

When thinking about it, I am quite sure that the assembly information is read directly from the file. If you need COM interoperability, you have to select Mixed Installation or manually mark the Generate COM interop registry keys for .NET Assembly check box on the Self-registration tab of the File Details dialog box.

The Generate COM interop... option is checked on the file.  The Registration Method option on that dialog is set to Do not register.  Is that correct?

Something is still missing on extraction I think, but I'm digging.

OK, so, if a file is to be registered with RegAsm outside of any install process, the File Details for that file in an install should be set to .NET Assembly and the Generate COM interop registry keys for .NET Assembly option on the Self-registration tab should be checked.  Is that all there is to it?

And is it true that something that requires RegSvr32 to register outside of an install will have its 'stuff' scanned and included automatically.  Or, do I have to set something on the Self-registration tab of File Details - Unordered, for example?

I thought it was best practice to stay away from Self-Registration if at all possible so I'm hesitant to use settings on this tab.

Any information appreciated!!!

I have very little experience with COM interop stuff. I do believe it should work like this, though.

You didn't answer if the .NET information was scanned correctly yet, or if the add to hash table was unchecked, like I referred to above. If you uncheck the 'Generate COM Interop...'  you should still be able to scan assembly attributes, and if it is not working, there is some underlaying problem preventing anything to be scanned in the first place.

Are you sure that the file is done correctly? We had a case with tools complaining that "Strong name signature verification failed" for some files and it ended up being a problem with Dotfuscator (debug dlls worked but not release). The strong name error appeared when attempting to drop the files to Windows assembly folder or when trying to extract assembly attributes (see for instance http://www.codeproject.com/KB/cs/ayassemblyattribu... ). The same error message was shown as above in Wise, though, about Failed to scan .NET information.

The file is not added to the Hash table (unchecked).

Generate COM Interop... is checked.

The reason I ask is that some of the assemblies are not set as .NET assemblies and I believe they should be.  I was laid off and was brought back 8 months later so I don't know why changes to the File Details for the effected files may have been made.

I just want to have everything set up as it should be to extract COM and/or Assembly information.

Next step is to check that the file is correctly made. Is it possible to drop the file into Windows assembly without errors? Or can the assembly attributes be read from the file with the code I linked to above?

I'll try to read from the file with the code linked to above.

After running RegAsm on a problematic file, all is OK.  I will say that during that process, we do get messages that the assembly doesn does not have a good strong name.  It still says that the file is registered and our application then runs properly.

If there is a problem with the strong name, it is possible that Wise is unable to populate the MSIAssemblyName table (probably including also the COM interop stuff). This is what I have seen at least once.