AppDomain.AssemblyResolve Event for resources files

Question

4.89/5 (2 votes)

See more:

Hello,

I'm implementing an AppDomain.AssemblyResolve (http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve.aspx[^]) eventhandler.

Everything works fine, I just return the Assembly when I can, otherwise just null like the documentation suggests. The event is called every time before .NET attempts to resolve the Assembly by itself.

Normally a AssemblyName.FullName is provided with the ResolveEventArgs This is easy to work with since each Assembly has an AssemblyName. Apart from names, the ResolveEventArgs sometimes also give a .resources file within an Assembly.

This behaviour is mentioned in the documentation:
Beginning with the .NET Framework 4, the ResolveEventHandler event is raised for all assemblies, including resource assemblies.

Not a problem, but what should I return when a .resources file is requested? Just the Assembly which contains the requested .resources file?
In my current infrastructure it's not hard to add, I just wonder if it's the right thing to do. Right now I just return null.

Thanks in advance

Posted 19-Sep-13 6:08am

wpte

Updated 19-Sep-13 6:09am

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 19-Sep-13 12:35pm

Actually, .resources file is not requested, but an assembly is requested, and only if the "standard" resolution has failed.
—SA

wpte 19-Sep-13 15:15pm

Since .NET 4.0 the event is allways called before .NET tries to resolve the Assembly by itself using the GAC or local libraries in the same directory as the executable.

url: http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve(v=vs.100).aspx
"Beginning with the .NET Framework 4, the ResolveEventHandler event is raised for all assemblies, including resource assemblies. In earlier versions, the event was not raised for resource assemblies. If the operating system is localized, the handler might be called multiple times: once for each culture in the fallback chain."

I was talking about embedded resources. I get requests in the event with a format like: "namespace.resourcename.resources" not the usual format from AssemblyName.FullName

Now it's not that hard to find the accompanying Assembly which contains the embedded resource. As Collin Kleine suggests, returning an Assembly which contains the resource might be a good idea. I will check this tomorrow

Sergey Alexandrovich Kryukov 19-Sep-13 15:45pm

I'm talking about embedded, too. But all events are invoked only when it fails in a default resolution.
I think returning of the Assembly which contains the resource is not just a good idea, but a requirement. Otherwise it won't be found at all. However, I don't know your scenario, what you are trying to achieve. If all your resource assemblies are found anyway, you should don't have to worry. Resource-only assemblies are relatively rare. Usually they are only the the satellites.
—SA

wpte 19-Sep-13 15:50pm

Allright. There's no way to check the correct version however. The only way to match the correct assembly is by matching strings. Bit unfortunate to be honest.

Still I'm convinced the event is called before .NET uses it's own resolver. I also get requests for System.something Assemblies which clearly need to be found in the GAC.

Also sorry for all the double posts, some code project maintenance was messing it up :(

Sergey Alexandrovich Kryukov 19-Sep-13 16:29pm

No problem. I tried to model the situation and now not quite sure. Are you trying to resolve the assembly bound statically, or via Assembly.Load/LoadFrom?
—SA

wpte 19-Sep-13 16:32pm

I load plugins in my programs using Assembly.LoadFrom. Some of these plugins require other Assemblies (references) which are not located in the GAC. With the event I attempt to load these references by trying to find them in some sub directories.

Sergey Alexandrovich Kryukov 19-Sep-13 16:55pm

Of course. This is a reasonable approach. However, you can work around this problem at all, by having your own mechanism of finding plug-ins. After all, the parameter of Assembly.LoadFrom is the string, location of the assembly's main module. Give it a correct path name in first place, say, find in by file search... This is how I do it.

...Yes, I got it, about other assemblies. But where they are located? (I mean the assemblies your plug-in assemblies depend on. I understand it's not GAC. There is no point to put plug-int in the GAC, it would defeat the purpose of plug-ins...)

—SA

Sergey Alexandrovich Kryukov 19-Sep-13 16:58pm

Another idea: I try to load all files as assemblies (including unmanaged, which will just fail) in certain directory, recursive sub-directory or not. Then I check up some types to find out it they implement my plug-in interface. Usually, I add a special assembly-level attribute to claim which type is the implementor, but check it up. To be able to unload an assembly, you need to load them in a separate AppDomain though. Do you know this technique? The only problem it to work through the AppDomain boundary...
—SA

wpte 19-Sep-13 17:04pm

I already use AppDomains extensively throughout my software.. Currently I only index the sub-directories once with reflection only load, so I can store the AssemblyName classes. When I'm done I throw away the AppDomain so no unnecessary memory is claimed. Since the construction of the cache only has to happen once, the resolving part is quite quick.

Sergey Alexandrovich Kryukov 19-Sep-13 17:14pm

Exactly.

I would think about working around the problem of assembly resolution. Frankly, I never tried to mess with the assembly resolution, as I either put all plug-ins in the same directory, or, when they are in another one, either did not have dependency assemblies (non-GAC) or simply used app.config "probing" feature. Do you know how it works? Tried? It does work...

Again, the worst work around would be putting plug-ins or their dependency assemblies in the GAC, it would be giving up and resorting to a very ugly way. It would pretty much defeat the purpose of plug-ins...

—SA

Sergey Alexandrovich Kryukov 19-Sep-13 17:14pm

Overall, this is an interesting question. By the way, I voted 5 for it. :-)
—SA

1 solution

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

collin kleine · Answer 1 · 2013-09-19T06:47:00

As you mentioned, it is not actually about .resources files, it is about embedded resources within a certain assembly, known as satellite assemblies.

Quote:
Beginning with the .NET Framework 4, the AssemblyResolve event is raised for satellite assemblies.

Source: http://msdn.microsoft.com/en-us/library/ff527268.aspx[^]

Quote:
satellite assembly

A .NET Framework assembly containing resources specific to a given language. Using satellite assemblies, you can place the resources for different languages in different assemblies, and the correct assembly is loaded into memory only if the user elects to view the application in that language.

Source: http://msdn.microsoft.com/en-GB/library/c83eyewf%28v=vs.80%29.aspx[^]

You will need to return the assembly containing the resource, as this short sentence tells you:

Quote:
The ResolveEventHandler for this event can attempt to locate the assembly containing the resource and return it.

Source: http://msdn.microsoft.com/en-us/library/system.appdomain.resourceresolve.aspx[^]

Hopes this help.

AppDomain.AssemblyResolve Event for resources files

1 solution

Solution 1

Add your solution here

Preview 0

AppDomain.AssemblyResolve Event for resources files

1 solution

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us