Projectsolver with a lot of assemblies.

Hi Lennart,

Great, glad to hear it! It should load fairly fast as long as you are caching the assemblies. If they are loading without cached info, it will take several seconds to get them all in. They could be loading without cached info if they have changed since last load too. Is this the case?

That's indeed what I was thinking about as well, but I tried it with the mscorlib assembly and a few system dll's (which shouldn't change) and it still takes quite a few seconds to load every time.
The way I use the resolver is like this:
When an editor is loaded, use the following code:
CachePath = Path.Combine(joaFolderInformation.TempPath, @"IntelliPromptCache\");
AddExternalReferenceForSystemAssembly("System");
AddExternalReferenceForMSCorLib();
Etcetera for other assemblies.

At closing/disposing, use this:
PruneCache();
Dispose();

I checked the temp path, and indeed there are 6 files there created 3 days ago. So, for some reason it seems the assembly gets loaded even if it's in the cache already. I'm probably misusing the cache at the moment, so could you give me a direction on how to avoid this?

Regards,
Lennart

I found the bug. Apparantly the behavious from joaFolderInformation.TempPath was changed a while ago, so it has become unuseful for the cache. I changed it to another folder and it works like a charm now.

Wonderful, glad to hear it!

I do have another question on the same subject though. We let our users link other assemblies in runtime as well, and remove links. When an assembly gets removed from the resolver, the cache doesn't seem to reflect this and the assembly still stays in the cache (at least it's still there in the cache folder). Is that normal behavior?

Yes it is there cached for the next time it is loaded so that it loads quickly. If there is any change in what is loaded later, it will be removed and replaced with an updated cache entry. Also, I believe calling PruneCache on app shutdown will delete cached items for which the assemblies no longer exist.