fix: Lazy loading of type libraries in case of type is class

[mavToday]

with commit #326 you introduced a lazy loading of type libraries.

the problem is, that this works only if there is a request of interfaces, but not of classes. I got a problem, that a method in assembly b could not resolve a class-type of assembly a, because the type library was not loaded yet.

In TypeProvider.GetVarType it resulted in a VT_UNKNOWN. This issues is only present with the changes of the given commit.

[mavToday]

I added some tests.

TypeLibTest.TypeLib_ShouldBeLoaded_By_Class failes before my changes, because the classtype is first requested.

[mavToday]

Okay, this change give us several issues with the unit-tests, because it loads the type-libs perhaps several times.

EDIT:
It tried to load typelibs for object, string, func`1, delegate and so on. And load typelibs than it should does. I now skipp the built in types and it works.

[mavToday]

can you restart the Code Style Check? looks like a bug in the pipeline

[marklechtermann]

can you restart the Code Style Check? looks like a bug in the pipeline

Yes, it's an error in the pipeline. I don't know why, but sometimes the pipeline doesn't find the .net runtime.

[marklechtermann]

Okay, this change give us several issues with the unit-tests, because it loads the type-libs perhaps several times.

EDIT: It tried to load typelibs for object, string, func`1, delegate and so on. And load typelibs than it should does. I now skipp the built in types and it works.

i have changed the behavior of the some test base classes. See #332
I hope this will stop (or at least reduce) the sporadic errors during test execution.
We now have so many tests that we end up with dead locks, especially when executing them in parallel.

[mavToday]

I updated the branch from main and adapted some changes.

BaseTest: There is no need anymore to create the dynamic-folder. Therefore i removed the code and the creation of unique assemblynames, because this was only needed for the file system.

DynamicAssemblyBuilder + TypeLibTest + TypeLibExporterNotifySink: I added the feature to add dependencies, because the typeresolver could not resolve them by the filesytem.

RegistrationServiceTest + HResult: I changed to assert to HResult, because this is not dependening on location. My system is german and it will create german messages (happend to me in net4.8 and changing the CultureInfo does no fullfill the job).

GlobalUsing: dotnet format --verify-no-changes

Thanks for the support

[marklechtermann]

@mlessmann can you take a look at our product to see if the changes have negative side effects.
This affects the TypeInfoResolver implementation that you last modified.

[mlessmann]

LGTM

[matthiasnissen]

Squash and merge...

[marklechtermann]

Fixed with version https://github.com/dspace-group/dscom/releases/tag/v1.15.0