DotNetProjectResolver and assembly resolving

SyntaxEditor .NET Languages Add-on for Windows Forms Forum

Posted 17 years ago by Miha Markic - Righthand
Version: 4.0.0270
Avatar
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 17 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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 17 years ago by Miha Markic - Righthand
Avatar
Sent via e-mail.

Miha Markic Righthand .net consulting and software development

Posted 17 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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 17 years ago by Miha Markic - Righthand
Avatar
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 17 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.1) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.