|
|
|
Community Member
|
|
I have a situation, where my MSBuild task (which also invokes PostSharp) has a shared DLL dependency with the target project that it's building. The task assembly, however, is located in a completely different directory path from the target assembly, which means they can't share the same physical file (they could if the dependency file was in GAC, but that's out of the question here). To work around this problem, I simply keep two copies of the shared dependency. But ...
When MSBuild task is loaded, it resolves its dependency to a local copy of the file. When PostSharp is invoked, however, it tries to resolve target assembly's dependency to its local copy, which is in another directory. The situation is detected and PostSharp emits a warning saying that another assembly with same name was already loaded from a different location.
Since files are the same (exact copies), I assume it shouldn't matter to PostSharp which one it loads. How would I go about convincing PostSharp to use the one that's already loaded instead of loading a second copy?
Mind you, this wasn't a problem in earlier CTPs. I've only noticed this after upgrading to RC1. It seems that the new AssemblyLocator does things a bit differently.
On the other hand, it looks like this change was done intentionally to allow a more configurable approach to assembly resolution. If this is the case, then, how does one tap into its powers?
Aleksander
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
The default lookup strategy is implemented in method AssemblyLocator.FindAssembly.
The following locations are tested, by order of priority:
- The event AssemblyLocator.LocatingAssembly is raised; so the host has a chance to hook the process.
- GAC is checked
- Resolved references are checked. The list of resolved references is provided from MSBuild; it is the list also passed to the C# compiler.
- The list of directories in the search path is checked.
However, there may be some interferences with the way how CLR locates assemblies. Sometimes, the CLR loads a second copy of the same assembly because it found it in a different directory than PostSharp does. It results in two copies of the same assembly being loaded. It may eventually cause casting exceptions (when a type of the first copy is casted into a type of the second copy), but most of the time you won't notice any problem.
The trick would be to force PostSharp to load the same copy of the assembly as the CLR would find. I guess the location passed to the C# compiler is not the location found by the CLR.
You can try to edit file PostSharp-1.5.targets and replace, at line 250:
ResolvedReferences=$(_ResolveAssemblyReferenceResolvedFilesAbsoluteAsCommaSeparatedList);
by
ResolvedReferences=;
Maybe it was a bad idea to put the C# compiler path into the PostSharp path, and will have to reconsider this.
Let me know if that helps.
-gael
|
|
|
|
|
Community Member
|
|
|
Let me know if that helps.
It helped, thanks.
But I'm wondering about this:
The following locations are tested, by order of priority:
- The event AssemblyLocator.LocatingAssembly is raised; so the host has a chance to hook the process.
Should I be subscribing to this event from my task, perhaps? Like, just in case, since you've gone through the trouble of putting it in there?
Aleksander
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Subscribing to AssemblyLocator.LocatingAssembly in your task may help, but is not a guaranty, since the principal assembly is loaded before your task is initialized.
Anyway, if you do it in your task, be sure to do it in the Initialize method and not in the Execute method, because dependencies of the main assembly will maybe be loaded before your task.
The proper way to do it is to implement a host, but this is a solution only if you have non-standard assembly locations.
|
|
|
|
Contacts
| Terms of Use |
Privacy Policy