We have a huge program. Approximately 250 DLLs. Of these, we have approximately 45 COM DLLs and 20+ .NET assemblies that have ComVisible classes in them.
Now we want to work on an XCopy deployable version... WHich means that we need to use Isolated COM. I have been experimenting with smaller projects and have the basic mechanics down of how it works.
Now the problem is that after having built the manifest for one application, it won't load. I used sxsTrace and it gives a useless error message.
Last four lines of sxstrace log:
INFO: Parsing Manifest File c:\src\v13\Debug-Win32\sta_net_DMModel.DLL.
INFO: Manifest Definition Identity is sta_net_DMModel,processorArchitecture="x86",version="1.0.0.0".
ERROR: Activation Context generation failed.
End Activation Context Generation.
The only thing useful is the name of the last DLL manifest it was trying to load. It was a .NET assembly that had a bunch of ComVisible classes in it that are not necessary at startup. I commented it out of the manifest and then the program loaded. But, as I looked at it, I noticed it had nearly 500 clrClass definitions in the manifest for the DLL. I had another DLL that had about a third of that number. I re-included the original DLL in my application manifest but commented out the ~170 clrClass DLL in the application manifest. When I did that, the application loaded to success.
So, it appears to me that there is some kind of limit on the maximum number of clrClass type information that can be loaded from the manifests for Isolated COM. It seems to be a cumulative thing because if I comment out either DLL, then it loads. But if I leave both in, then it won't load.
Is there a documented limit to the amount of type information that the manifest loaders can process?
Is there a registry setting I could change, or some constant I could add to my manifest to bump up the limit? I have no idea what the limit is, but there seems to be one.
Running depends.exe gives this:
Error: The Side-by-Side configuration information for "c:\src\v13\debug-win32\STATIST.EXE" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).
I eventually found the problem. It was not that there were too many clrClass'es in the manifests. I used ProcMon and PerfView to try and see the problem, but they didn't show much.
Eventually, I just started editing on the manifests and deleting and undeleting clrClass entries from the manifest until I found the problem. I sort of did a binary search...delete half and see if it goes away. If not delete the other half and see if the problem goes away. Then repeat with the problem section and keep halving until the offending clrClass (or clrClasses) is found.
To make a long story short, I found that two different clrClass'es in the two DLLs I was having problems with had the same CLSID. The manifest loader was erroring out because there were COM visible classes in the two DLLs that had duplicate CLSIDs. Somewhere, someone had made a mistake with copy and paste or something. However, the error message from the sxstrace utility did not specify what the error was. It just gave the generic error. To triple check, I wrote a utility to check the CLSID, ProgID, and class names of all the COM visible classes in the two libraries. I eventually found that there were 3 CLSIDs that were duplicates.
So, if anyone ever looks at this in the future, they can see that duplicate CLSIDs (or ProgIDs?) in the clrClass declarations in the .NET assemblies might be their problem.