Error 1928. Error registering COM+ Application

[el_sid]

When we try and install our COM+ components using a client proxy from our Windows 2003 machine onto our XP machines we always get an error during installation on the client machine (see below). Now if we select the option "Save COM+ Component in 1.0 format..." when creating the client side proxy installer on the server the installation always works. Now my understanding is that XP and 2003 use the same version of COM+ and I have also checked to make sure that our COM+ component is not on the client machine when we run the client proxy installation (checked the gac and also the registry). Any help would be appreciated in solving this problem as we would like to keep our proxies in the 1.5 COM+ format.

First Error:

System.IO.FileNotFoundException: File or assembly name YW.Applications.ROD2.Common, or one of its dependencies, was not found.
File name: "YW.Applications.ROD2.Common"
at System.Reflection.Assembly.GetExportedTypes()
at System.Runtime.InteropServices.RegistrationServices.GetRegistrableTypesInAssembly(Assembly assembly)
at System.Runtime.InteropServices.RegistrationServices.RegisterAssembly(Assembly assembly, AssemblyRegistrationFlags flags)
at System.EnterpriseServices.Internal.Publish.RegisterAssembly(String AssemblyPath)

=== Pre-bind state information ===
LOG: DisplayName = YW.Applications.ROD2.Common, Version=1.0.1566.24227, Culture=neutral, PublicKeyToken=2e97d1cc03514dcd
(Fully-specified)
LOG: Appbase = C:\WINNT\system32LOG: Initial PrivatePath = NULL
Calling assembly : YW.Applications.ROD2.Components.UserService, Version=1.0.1566.24233, Culture=neutral, PublicKeyToken=07faf84f6e0dbcd2.
===

LOG: Publisher policy file is not found.
LOG: Host configuration file not found.
LOG: Using machine configuration file from C:\WINNT\Microsoft.NET\Framework\v1.1.4322\config\machine.config.
LOG: Post-policy reference: YW.Applications.ROD2.Common, Version=1.0.1566.24227, Culture=neutral, PublicKeyToken=2e97d1cc03514dcd
LOG: Attempting download of new URL file:///C:/WINNT/system32/YW.Applications.ROD2.Common.DLL.
LOG: Attempting download of new URL file:///C:/WINNT/system32/YW.Applications.ROD2.Common/YW.Applications.ROD2.Common.DLL.
LOG: Attempting download of new URL file:///C:/WINNT/system32/YW.Applications.ROD2.Common.EXE.
LOG: Attempting download of new URL file:///C:/WINNT/system32/YW.Applications.ROD2.Common/YW.Applications.ROD2.Common.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/COMPlus Applications/{AE505A3F-A951-4C70-898B-9A4FA9449AB6}/YW.Applications.ROD2.Common.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/COMPlus Applications/{AE505A3F-A951-4C70-898B-9A4FA9449AB6}/YW.Applications.ROD2.Common/YW.Applications.ROD2.Common.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/COMPlus Applications/{AE505A3F-A951-4C70-898B-9A4FA9449AB6}/YW.Applications.ROD2.Common.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/COMPlus Applications/{AE505A3F-A951-4C70-898B-9A4FA9449AB6}/YW.Applications.ROD2.Common/YW.Applications.ROD2.Common.EXE.

Second Error:

Product: UserService (Application Proxy) -- Error 1928. Error registering COM+ Application. Contact your support personnel for more information.

[Ying-Shen Yu[MSFT]]

Hi,

It seems like there is an assembly binding failure in the installation
process.

Did you use some types from some other assemblies in the exported types of
your COM+ proxy assembly?

You may also check the fusion log to get more information.
Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.

[Ying-Shen Yu[MSFT]]

I mean if there is any types from the "Common" assembly was used in the
exported Types of your ServicedComponent assembly.

In the result of Assembly.GetExportedTypes(), is there any types which
derives or implements a type defined in the "Common" assembly?

If so, you may try adding the Common assembly into the GAC of client
machine.

[Ying-Shen Yu[MSFT]]

Hi,

I'm not sure why this problem is not occurred in COM+ 1.0 proxy setup
package, but it's probably because the 1.0 format will not add the proxy
assembly into GAC( The exception seems like thrown in the process of
loading the proxy assembly when adding to GAC).

If the problem could resolved by register the "Common" assembly into the
GAC of client machine.
I suspect this problem was caused by the assembly binding failure, when
loading the proxy assembly and get the exported types, CLR needs retrieving
the base type of every export type, in my test if the type was derived
from/implemented a type defined in another assembly, CLR needs loading that
assembly as well to get the meta data of the base type.

So if you need to make clear what types depends on the "Common" assembly,
you should check the result of Assembly.GetExportedTypes first.

Thanks!

[Ying-Shen Yu[MSFT]]

Hi,

From the exception, it seems the problem is still caused by the type
dependency failure.
Just a guess, it seems the client loaded the Common assembly and execute
the code on the client machine.

Have you found out what types in the Common assembly did your
exported proxy assembly depenend on?
Also maybe you could let me know more about the Common assembly, basically
it should only contains those types which could be used both side and deos
not depends on assemblies which might not exist on either side.

Consider this issue is a bit off the Registering COM+ issue, could you drop
a new post to the group, I'll follow with you in that thread.

[Ying-Shen Yu[MSFT]]

Sorry, it'a typo, I mean drop a post to this group.

I'd like to reproduce this error on my system to do some further
investigation,
however I'm not clear how to reproduce it since the error is related to the
implementation of the method ValidateCurrentUser() in the Common assembly.
could you send me a simple repro sample for this issue?

If it's not easy to make the repro, I'd like to take a look at the related
code snippet related to this exception.

Thanks for your patience.

[Ying-Shen Yu[MSFT]]

Hi Sid,

Sorry for the late reply, I was out of the office yesterday.
Now I'm able to reproduce this problem on my system,
I'll go on investigating this issue and update you as soon as possible.

Thanks for you patience.

[Ying-Shen Yu[MSFT]]

Hi,

After some research, I found this is expected behavior, the client app
needs to load the ServicedComponent assembly, and the assembly was loaded
by CLR loader. when calling createinstance, CLR loader need to resolve all
types in the code of that type, which caused this exception.

So you need put all the assemblies referenced in the ServicedComponent
assemblies into the GAC or same with the app directory on the client
machine.

I haven't figured out why the Components.dll is not needed if exported in
v1.0 format, maybe there are some COM+ attribute not defined in 1.0 format,
which caused different COM+ runtime uses difference loading mechansim.

If you have any further questions on this issue, please update this thread
to let me know.

Have a nice day!

[Ying-Shen Yu[MSFT]]

Hi,

"Now this implies that the Common.Components.dll is being run from our
client machine and not the COM+ server."

The Components.dll is still running at the server side, these assemblies
installed on client are only used to provide type information to let the
Commer.dll loaded properly, and Commer.dll itself is also used to provide
type information to CLR and the COM+ runtime. the actual method are running
at server side.

I also consulted the a guy in Enterprise Service Dev-Team, he confirmed
that the Components.dll was needed in this scenario. The proxy installs the
commer.dll on the client because it is needed for type information. When
commer.dll is loaded the assembly components.dll is required due to the
dependency.

If you really need to break the dependency between commer.dll and
components.dll, the only way we can thing of after discussion is to access
types in components.dll using reflection at runtime. A small proxy class
could be built into commer.dll that calls Assembly.Load(components.dll) and
then creates instances of the types needed. That's not a great solution but
could work if components.dll cannot be installed on clients.

BTW: Have you did a complete test on your client app when using v1.0 format
proxy?

Thanks!

[Yan-Hong Huang[MSFT]]

Hello,

Currently we are working with support engineer on it and will reply here
with more information as soon as possible.

If you have any more concerns, please feel free to post here. Thanks very
much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[David Qiu]

I can not answer your question on top off my head. It needs some time to
investigate.
I would suggest you to contact Micrososft Developer Support and open a
support incidence
if you have a MCP account. In the meantime you can use this tool to get a
binding log:

Assembly Binding Log Viewer (Fuslogvw.exe)

David
Microsoft