TypeManager.TypeAssemblies error

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?

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.

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!


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

		IEnumerable<Assembly> domainAssemblies = AppDomain.CurrentDomain.GetAssemblies();
		IEnumerable<Assembly> domainAssemblies = TypeManager.GetTypeAssemblies();

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.

1 Like

Thanks, logged as bugs://83073

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?

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

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.

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

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.

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.

1 Like

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.

1 Like

bugs://83073 got closed with status fixed.