How do I create and use a .NET metadata-only 'Reference Assembly'?

Question

Since version 3.0, .NET installs a bunch of different 'reference assemblies' under C:\Program Files\Reference Assemblies\Microsoft...., to support different profiles (say .NET 3.5 client profile, Silverlight profile). Each of these is a proper .NET assembly that contains only metadata - no IL code - and each assembly is marked with the ReferenceAssemblyAttribute. The metadata is restricted to those types and member available under the applicable profile - that's how intellisense shows a restricted set of types and members. The reference assemblies are not used at runtime.

I learnt a bit about it from this blog post.

I'd like to create and use such a reference assembly for my library.

1. How do I create a metadata-only assembly - is there some compiler flag or ildasm post-processor?
2. Are there attributes that control which types are exported to different 'profiles'?
3. How does the reference assembly resolution at runtime - if I had the reference assembly present in my application directory instead of the 'real' assembly, and not in the GAC at all, would probing continue and my AssemblyResolve event fire so that I can supply the actual assembly at runtime?

Any ideas or pointers to where I could learn more about this would be greatly appreciated.

Update: Looking around a bit, I see the .NET 3.0 'reference assemblies' do seem to have some code, and the Reference Assembly attribute was only added in .NET 4.0. So the behaviour might have changed a bit with the new runtime.

Why? For my Excel-DNA ( http://exceldna.codeplex.com ) add-in library, I create single-file .xll add-in by packing the referenced assemblies into the .xll file as resources. The packed assemblies include the user's add-in code, as well as the Excel-DNA managed library (which might be referenced by the user's assembly).

It sounds rather complicated, but works wonderfully well most of the time - the add-in is a single small file, so no installation of distribution issues. I run into (not unexpected) problems because of different versions - if there is an old version of the Excel-DNA managed library as a file, the runtime will load that instead of the packed one (I never get a chance to interfere with the loading).

I hope to make a reference assembly for my Excel-DNA managed part that users can point to when compiling their add-ins. But if they mistakenly have a version of this assembly at runtime, the runtime should fail to load it, and give me a chance to load the real assembly from resources.

Answer 1

To create a reference assembly, you would add this line to your AssemblyInfo.cs file:

[assembly: ReferenceAssembly]

To load others, you can reference them as usual from your VisualStudio project references, or dynamically at runtime using:

Assembly.ReflectionOnlyLoad()

or

Assembly.ReflectionOnlyLoadFrom()

---

If you have added a reference to a metadata/reference assembly using VisualStudio, then intellisense and building your project will work just fine, however if you try to execute your application against one, you will get an error:

System.BadImageFormatException: Cannot load a reference assembly for execution.

So the expectation is that at runtime you would substitute in a real assembly that has the same metadata signature.

If you have loaded an assembly dynamically with Assembly.ReflectionOnlyLoad() then you can only do all the reflection operations against it (read the types, methods, properties, attributes, etc, but can not dynamically invoke any of them).

---

I am curious as to what your use case is for creating a metadata-only assembly. I've never had to do that before, and would love to know if you have found some interesting use for them...

Answer 2

If you are still interested in this possibility, I've made a fork of the il-repack project based on Mono.Cecil which accepts a "/meta" command line argument to generate a metadata only assembly for the public and protected types.

https://github.com/KarimLUCCIN/il-repack/tree/xna

(I tried it on the full XNA Framework and its working afaik ...)