DotNetProjectResolver and assembly resolving

Posted 16 years ago by Miha Markic - Righthand

Version: 4.0.0270

Hi guys,

I have some problems with DotNetProjectResolver and assembly resolving.
Imagine I have a strong signed assembly A. My application is referencing a local copy of A. Then I want to dotNetProjectResolver.AddExternalReference(B) where B is referencing its own local copy of A.
I get an exception saying that same assembly can't be loaded from two different places (A and B have different paths to the same assembly). The same situation is perfectly handled by fusion (it just reuses the already loaded assembly).

Is this a bug?

Miha Markic Righthand .net consulting and software development

Comments (5)

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Miha,

We are just calling native .NET framework reflection-only assembly load code. So I don't think it's a bug in our code but that said, sometimes there are workaround like events that can be attached to in the Microsoft reflection objects that allow us to work around issues. If you would like, maybe put together a small sample that shows this happening and email it over.

Alternatively, you can pass us Assembly references directly so you bypass any of our code that could be running into this issue.

Actipro Software Support

Posted 16 years ago by Miha Markic - Righthand

Sent via e-mail.

Miha Markic Righthand .net consulting and software development

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Miha,

We do use a separate AppDomain for loading reflection data and I see the problem in the sample you sent. You didn't set the DotNetProjectResolver.CachePath. If you don't do that, it won't use the separate AppDomain and you will run into issues.

Always make sure the CachePath is set before loading any assemblies into the DotNetProjectResolver. That should get you going.

Actipro Software Support

Posted 16 years ago by Miha Markic - Righthand

OK, got that. Perhaps you could set CachePath by default to user's temp folder.

Thanks

Miha Markic Righthand .net consulting and software development

Posted 16 years ago by Actipro Software Support - Cleveland, OH, USA

Good idea, this is now added for the next maintenance release:
Updated the DotNetProjectResolver so that if a CachePath (required for proper functionality) is not specified, it will write to a child folder in the user's temp folder.

Actipro Software Support

The latest build of this product (v24.1.0) was released 2 months ago, which was after the last post in this thread.

Comments (5)

Add Comment