When developing my Sample demonstrating ClickOnce deployment of unmanaged app with COM component implemented in managed assembly without using GAC or Registry and without requiring admin rights I first got it working on my Vista laptop. I didn’t get it right at the first attempt, but by analyzing events in Event Log and using SxSTrace tool I was able to identify and correct any problem, mostly in manifest files. Then I tried to run it on my Windows Server 2003 workstation and it didn’t workL. The error message said only that “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.” Not very helpful. Event log entries in the Event Log were a bit more specific and said that “Dependent Assembly AssemblyWithComComponents could not be found and Last Error was The referenced assembly is not installed on your system”.
Unfortunately SxSTrace tool is not available on Windows Server 2003, so I couldn’t use it to diagnose the problem.
I knew from my earlier development that typically if you don’t use consistent definition of assembly identity between the client manifest and the manifest embedded in the dependent assembly you gets the following event entry: “Component identity found in manifest does not match the identity of the component requested”. But I was getting a different error, so I thought that the source of the problem is not related to mismatched assembly identities. And I knew that if you made a syntax error in the manifest file, the event log entry will state it very clearly, for instance “The element assemblyIdentity2 appears as a child of element urn:schemas-microsoft-com:asm.v1^dependentAssembly which is not supported by this version of Windows”. But again, I was getting a different error. After many attempts to get it working I finally noticed that the assemblyidentity element in the client assembly had the language attribute specified as “language=”neutral”. But my embedded assembly didn’t! And that was the problem! Apparently SxS loader in Vista is able to match an assembly identity with “language=”neutral” attribute specified with an assembly identity that doesn’t have this attribute specified. And it makes sense since “neutral” is the default value. But Windows XP and Windows Server 2003 don’t work that way. So lesson learned: ALWAYS make sure that the assemblyidentity element in the client manifest matches the embedded manifest in the dependent assembly. And if you get an error that a dependent assembly could not be found, make sure that the language attributes match. And always test your solution on all operating systems that you claim to supportJ.
Hopefully next posts will be about lesson learned from doing real solutions architecture work and not from chasing mismatched attributes in manifest filesJ.
Senior Solutions Architect
GISV Architecture Team