Unable to get assembly information

[gsRon]

I updated a machine OS from Server 2008 to Server 2008 R2 and now I get 'Unable to get assembly information' when building projects.

I was using 9.03 and have tried 9.04, but am getting the same error. The projects do build under Server 2008 on other machines.

Any ideas?

[ohali]

I'm having the same problem on the machine where I initially installed IA9. OS is Vista SP1.

I've posted this problem a couple of weeks ago, but for some strange reason all threads about this problem never even get an answer

[MichaelNesmith]

You can try sending us the assemblies in question?

[ohali]

Sure. I'll send you an assembly where I get this error in a couple of minutes by mail.

But I'm not sure if you can reproduce this error. It seems like this has something to do with the system where IA9 is installed.

If I can check something on my system for you, don't hesitate to ask.

[MichaelNesmith]

Thanks for sending the file. Is the assembly 64 bit and your build environment 32 bit?

[ohali]

The assembly is "anycpu" which means it can be used in 64 Bit and 32 Bit environments.
There are other assemblies that have been created the same way and have similar flags set (checked via corflags.exe), that can be processed by IA9 without any problem. Should I send you an example of such a file as well, so that you can find a difference?

[MichaelNesmith]

I'm not sure I'd be able to find the difference simply by doing a binary DIFF on the two files

It would help if you can narrow down the issue a little further?

[ohali]

It's a bit hard to narrow the problem if I do not know where to look at.

When I run IA9 and click on Assemblies a program called mGacInfoX.exe is running for a while. Am I guessing right, that this program is getting the assemby information? I think this program is causing the problem, because it is not able to get the information correctly.

Can I run this program via the command line? What command line arguments do I have to provide? Does this program has to be run as an Administrator?

[MichaelNesmith]

Yes, the InstallAware IDE runs this program which is .NET based (the IDE is free from .NET for maximum native code performance).

Since you mentioned some assemblies work fine and others fail, I thought it might be more helpful to look at the assemblies themselves, rather than the program which is very basic. It shouldn't require admin rights, in fact the program code can be summarized as follows:

Code: Select all

System.Reflection.Assembly.LoadFile
System.Reflection.Assembly.GetName.FullName

[ohali]

Ok, I think I have found some hints to solve the problem. In my case I've had two different types of assemblies that didn't work:

1. Third party components from different vendors (ComponentOne, Combit, ...)
2. Interop-Assemblies that have been created by Visual Studio.

At first I found a difference between the third party components that worked and those that didn't work: the working ones have been in the GAC! After I installed the other ones in the GAC, they worked as well.

After that I recreated the interop assemblies with tlbimp and gave them a strong name (with /keyfile). Now these files work as well.

It seems that there is a problem with reading the assembly information if the assemblies are not strong named and/or are not installed in the GAC.

Hopefully you can find the source of this problem to prevent others from getting caught in that trap.

Anyway, for the first time I'm now able to build a complete setup

[MichaelNesmith]

You are correct, the full exception result of your assembly is:

System.IO.FileLoadException: Could not load file or assembly 'Interop.ADOX, Version=6.0.0.0, Culture=neutral, PublicKeyToken=ad2184c5c76d11ab' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
File name: 'Interop.ADOX, Version=6.0.0.0, Culture=neutral, PublicKeyToken=ad2184c5c76d11ab' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
The Zone of the assembly that failed was:
MyComputer
at System.Reflection.Assembly.nLoadFile(String path, Evidence evidence)
at System.Reflection.Assembly.LoadFile(String path)
at gacnet20x.Program.Main(String[] args) in E:\\InstallAware\\gacnet20\\gacnet20x\\Program.cs:line 17

It would seem the solution is to use strong names in your assemblies, which is a best-practice for authoring assemblies AFAIK.

[ohali]

You are right, that's best-practice.

But please keep in mind that there was a problem with some third-party components as well, which have had a strong name and still made problems. Perhaps you can have a closer look at that part.

And ... it would really have helped me if mGacInfoX would have provided the full exception message. Then one knows where to look at.

Anyway, problem solved, thanks for your patience!

[ohali]

I'd like to re-confirm this bug. I've moved to a new PC and got the error message "unable to get assembly information" again.
After installing the (third party) assemblies (which are strong named) to the GAC the error message disappears.
I'd like to emphasize that this should be corrected in a future version because assemblies should not be installed in the GAC according to the guidelines from MS.

[neillans]

Care to elaborate on this?

"assemblies should not be installed in the GAC according to the guidelines from MS."

That's contrary to my understanding ...

[ohali]

No problem. The Windows 7 Client Software Logo Program Requirements state:

"A waiver is required for applications writing to the global assembly cache (GAC). Generally .NET applications should keep assembly dependencies private, and store it in the application directory unless sharing an assembly is explicitly required."