TypeManager.TypeAssemblies error

[estebanp]

Hi, im getting exactly the error described on the post below on a .net 4.7.2 service using a nuget/dll client proxy built on .net 2.0 standard use to call a Delphi Server.

This error DOES NOT happen in two development machines where we tested it. It only happens on two of our servers. Other services running exactly the same combination of nugets, frameworks and calling the same Delphi server work fine on the same machines.

The two servers are running on WSERVER2008R2ENT.

Anything I can look for? Also why is even required to call the TypeManager? is that something that is supposed to be done?

Problems with a custom login method w/.NET Core 2.1

I am working on a .NET Core 2.1 client when I execute this code: Using libraries from: C:\Program Files (x86)\RemObjects Software\Data Abstract for .NET\Bin.NETStandard version: 9.4.109.1377 var ls = CoLoginService.Create(lMessage, lChannel); var result = ls.LoginChronicle2(userId, password, UserTypeEnum.ChronicleMobileAndroid, out loggedInUserInfo, cvsl.ToArray()); I get this exception: Unknown class found in stream: UserInfo. Either the corresponding .NET type is not defi…

[estebanp]

Ok, so I have more information.

We have a nuget that wraps the .net dlls for our services. It seems that one of the versions of the nuget did not include on its nuspec the libraries for both versions of .net (framework and standard/core) but only the .core/standard.

Inside the solution there are dlls that are set to be .net standard and some others to be .net 4.7.2 and somehow by not including both on the nuspec some issue was being caused and the error message will occured.

After adding both libraries and releasing a new nuget, the service is working now.

Hopefully anyone attempting to use .net standard clients will find this useful. Dont know the reasons of why it happened but at least there is hint on how it got solved.

[mh (marc hoffman)]

Is this actually a fatal exception, or maybe just one that the debugger shows, but that’s caught? Can you post the complete call stack and error message? Thanx!

[antonk]

Hello

@estebanp

Inside the solution there are dlls that are set to be .net standard and some others to be .net 4.7.2 and somehow by not including both on the nuspec some issue was being caused and the error message will occured.

Most probably missing .nuspec metadata caused MSBuild to use the .NET Std-targeted assemblies instead on .NET FX or .NET Core ones.

The main difference in this case that caused the exception to appear was that .NET Standard assemblies use type resolving different from one used in .NET FX or .NET Core assemblies.

It can be narrowed down to

#if FULLFRAMEWORK || NETCORE
		IEnumerable<Assembly> domainAssemblies = AppDomain.CurrentDomain.GetAssemblies();
#else
		IEnumerable<Assembly> domainAssemblies = TypeManager.GetTypeAssemblies();
#endif

In other words, NET Std relies on manual registration of type assemblies in the TypeManager while other do use AppDomain.CurrentDomain to list assemblies.

The reason for this is that .NET Std was meant to be used on platforms where previously manual assembly registration was used.

We do have plans to finally unify the codepaths here, but we had to approach this with caution, otherwise a existing code can be broken (f.e. TypeManager).

For your convenience I’ll log the integration issue again and will link it to this topic, so you’ll see the progress on it.

[RemObjectsSoftware (RemObjects)]

Thanks, logged as bugs://83073

[estebanp]

Just to clarify and for others to read.

If you want to use the DLLs from the

C:\Program Files (x86)\RemObjects Software\RemObjects SDK for .NET\Bin.NETStandard

In order to target .net standard / core you HAVE to register every structure/class I use on my RODLs?

[mh (marc hoffman)]

Not each structure, just each assembly (ie your main exe, and any other dependent .dlls that might also define ROSDK types.

[estebanp]

Thank you Marc for the quick response.

It is good that it was logged for future improvement. It is definitely an inconvenience because we distribute our structures on a lot (x2) nuget packages targeting different architectures and frameworks, adding some sort of initialization section to them so it is invisible to their users that they need to register the assemblies will be kind of a pain.

We are going to rollback our .net 2.0 move and target 4.7.2 in the meanwhile hoping to have that addressed in the future.

[mh (marc hoffman)]

@estebanp

It is definitely an inconvenience

I understand it is (or was) a limitation of .NET Standard (vs. the full framework).

@estebanp

because we distribute our structures on a lot (x2) nuget packages targeting different architectures and frameworks,

Note that only the assemblies that contain the structs you actually send across the network need to be registered, not every .dll your project depends on.

[antonk]

Please drop a mail to support@ with your account name and a link to this topic.

I’ll try to do my best to get this issue sorted out early next week.

[estebanp]

Thank you for the clarifications marc,

We usually create two sets of nugets, a client proxy and a model that contains the data for each service. Our basic service template uses 4 “micro” services: Service Registration, Authentication, Notification and Health, from there every service interacts with other services depending on their needs.

This implies that as a minimum one “micro” service will be in touch with 6-7 other services. Thats 6 or 7 registrations at both sides of the wired, from there mileage will vary.

It is doable, but not something I could just ask everyone to update to the new client proxies and ask them to include some extra registration code.

@antonk thank you, take your time and do it right. We’ll proceed for now with 4.7.2 and on the next dev cycle if available we will try the .net standard. I’ll drop you an email later today.

[RemObjectsSoftware (RemObjects)]

bugs://83073 got closed with status fixed.