Develop Reference

Problem in understanding assembly, and resources from a different assembly

The book is WPF Unleashed, and it tells that binary resources from a different assembly can be used as well, but what it doesn't explain is the concept of assembly and the need to pack resources in a different assembly. So i put the question here.
I tried to google it, but couldn't find the answer that allows me to comprehend what is an assembly in WPF, and how to create an assembly that just consist of resources using Visual Studio 2010?
And second, what is the advantage of packing resources in a different assembly except that they can be updated without shipping a brand new assembly of the product.

WPF assemblies are no different than any other .NET assembly in terms of structure and use. They are the fundamental unit of deployment of an application (web, windows, service, etc) and contain resources for the execution of a .NET application.
I'd take a look at the MSDN article on assemblies -- it's pretty straightforward.
As for your second question, I'll repeat my comment here. You already answered your question about packing resources in a separate assembly -- you can redeploy that separate assembly without having to redeploy or rebuild your original product. You gotta like that. Being able to drop in to your bin directory an assembly that has, say, a bunch of custom widgets that you want to display on your site and having your site automatically probe the bin directory and grab all of the resources that meet its criteria is wonderful. I don't end up having to touch my main app -- just create a new project for my new resources, compile it to a separate assembly (DLL in this case) and just drop it in 'bin' and voila! Awesome.
Hope this helps.

Here's a starting point:
wiki on .NET Assemblies
An Assembly is similar to a C++ DLL, but it has some other characteristics, such as metadata which describes the classes that are available for use.
One advantage of packing resources in a different assembly is that it gives a single point of reference - if you need to reuse resources across an application (or many applications) that use multiple assemblies, then this is a good strategy to adopt. This is particularly useful if those resources need to be localized.
WPF does not define assemblies, the concept is defined across the .NET Framework.

Plugin Situation: What to do with dependent libraries?

I have a MEF-based application which uses adapters to process files. It uses configuration files to determine which directories to watch and which adapter to use to process each type of file. Plugins take the form of a .dll that implements a common interface.
Each .dll requires its own set of dependent libaries. For instance, plugin1.dll might need to use apilibrary.dll and xmllibrary.dll. It is also possible that at a later date I might want to add plugin2.dll, and plugin2.dll might use xmllibrary.dll as well. These dependent libraries are updated regularly, so I can't count on plugin2.dll using the exact same version of xmllibrary.dll used in plugin1.dll.
I'd like to compile each plugin to one .dll file that invisibly includes within itself all of its dependent libraries, which seems like one way to solve this problem. Alternately, I'd like to figure out how each .dll file can look for its dependent libaries in a subfolder, which I believe would also reduce the possibility of versioning conflicts. Or maybe there's a dead simple solution to this problem that I haven't even considered (which is always very, very likely).
Any thoughts?

You should probably try to get this to work with standard .NET loading rules. However, if you do need to control exactly how assemblies are loaded and which versions are loaded, this blog post shows how: Using Loading contexts effectively

I guess you need to weigh up deployability vs. maintenance. The simple solution is to use a tool called ILMerge. ILMerge takes your project output and can take other assemblies and merge them together. This enables you to wrap up all of the assemblies that your plugin is dependent on, and merge them into a single assembly. Optionally you can do things like re-signing with your public key, etc. Here is a good read: Leveraging ILMerge to simplify deployment and your users experience by Daniel Cazzulino.
But while that is good, what happens if a new version of the referenced assembly is distributed that corrects bugs in that which you have embedded? By the rules of Fusions assembly loader, when it loads the types from your referenced assembly, it will see that they have already been loaded, so there is no reason for it to load the updated version. This would then mean you need to recompile your plugin and merge the newer referenced assembly again.
My question would be, is it really that important to ensure a specific version is used? If a newer version provides an updated implementation (that doesn't break backwards compatibility) then surely this should benefit all plugins that need to reference it?
As for as how assemblies are loaded in reference to each other, have a read of Understanding .Net Assemblies and References, which is an invaluable piece of information.

MEF uses standard .NET assembly loading, and everything's loaded in a single AppDomain. You have very little control over how dependencies are loaded - as they just get loaded automatically by the CLR when the assembly is injected via MEF. Normal CLR assembly loading rules apply when using MEF, so dependencies will be loaded as if they were a dependency of your application - no matter where they're located or referenced.
For the most part, if the plugins and their dependencies are properly written, you most likely will not need to worry about this. As long as the versioning in the dependencies is correct, it will likely just work.

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

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.
How do I create a metadata-only assembly - is there some compiler flag or ildasm post-processor?
Are there attributes that control which types are exported to different 'profiles'?
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.

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...

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 ...)

Yes, this is new for .NET 4.0. I'm fairly sure this was done to avoid the nasty versioning problems in the .NET 2.0 service packs. Best example is the WaitHandle.WaitOne(int) overload, added and documented in SP2. A popular overload because it avoids having to guess at the proper value for *exitContext" in the WaitOne(int, bool) overload. Problem is, the program bombs when it is run on a version of 2.0 that's older than SP2. Not a happy diagnostic either. Isolating the reference assemblies ensures that this can't happen again.
I think those reference assemblies were created by starting from a copy of the compiled assemblies (like it was done in previous versions) and running them through a tool that strips the IL from the assembly. That tool is however not available to us, nothing in the bin/netfx 4.0 tools Windows 7.1 SDK subdirectory that could do this. Not exactly a tool that gets used often so it is probably not production quality :)

You might have luck with the Cecil Library (from Mono); I think the implementation allows ILMerge functionality, it might just as well write metadata only assemblies.
I have scanned the code base (documentation is sparse), but haven't found any obvious clues yet...
YYMV

What is a .NET managed module?

I know it's a Windows PE32, but I also know that the unit of deployment in .NET is an assembly which in turn has a manifest and can be made up of multiple managed modules.
My questions are :
1) How would you create multiple managed modules when building a project such as a class lib or a console app etc.
2) Is there a way to specify this to the compiler(via the project properties for example) to partition your source code files into multiple managed modules.
If so what is the benefit of doing so?
3)Can managed modules span assemblies?
4)Are separate file created on disk when the source code is compiled or are these created in memory and directly embedded in an assembly?
EDIT:
#Jon:
For 2):So, does compiling/building source in visual studio always create a single managed module? If so then I fail to understand as to why VS doesn't provide a mechanism to do so in spite of the fact that .NET supports doing so.
I agree that it would be unmanageable to create an assembly with modules from different languages. Is that the only reason why .NET allows creating multi module assemblies?
I read in Richter's CLR via C# that modules can also span assemblies, and this can help keep assembly sizes down, and reduce memory footprint by downloading assembles on demand when certain functionality is invoked for the first time, but I'm not quite sure as to why would one want to span a module across assemblies, why not just create a new assembly which implicity creates a new module in the process. You would still gain the same benefits.
Item 4) was in regards to ".netmodule" files.
As part of the VS build process I haven't seen any ".netmodule" files created in the obj directory. I've typically noticed .pdb, .dll/.exe and a *FileListAbsolute file and hence the question on whether any separate files are created for managed modules.
EDIT:
#Jon: Here is the excerpt from CLR via C#(3rd edition) Pg 43:
Maybe I'm misreading this but it sounds to me that a module (which is a file belonging to an assembly) can be downloaded on demand.
"For example, an assembly can consist of several types.
You could put the frequently used types in one file and the less frequently used types in
another file. If your assembly is deployed by downloading it via the Internet, the file with
the infrequently used types might not ever have to be downloaded to the client if the client
never accesses the types. For example, an independent software vendor (ISV) specializing in
UI controls might choose to implement Active Accessibility types in a separate module (to
satisfy Microsoft’s Logo requirements). Only users who require the additional accessibility
features would require this module to be downloaded.
You configure an application to download assembly files by specifying a codeBase element
(discussed in Chapter 3) in the application’s configuration file. The codeBase element identifies
a URL pointing to where all of an assembly’s files can be found."

1) You can't do this in Visual Studio. You can do it from the command line using:
csc /target:module Foo.cs Bar.cs
In this case you'd end up with a fle called Foo.netmodule
2) See question 1 - you can't do this from Visual Studio, but you can do it from the command line. I don't know of any benefits. EDIT: I agree with Andrew's statement that you could create an assembly from multiple languages this way - but I believe it would be impractical. You'd have to work out an appropriate dependency chain so that you could build one complete module first, then the next etc... at that point, why not just build separate assemblies in the first place? It would effectively be an extra accessibility domain, admittedly... but that's about all. I believe the disadvantages of this are likely to outweigh the advantages in almost all scenarios. If you really want to build a single assembly, you can always use ilmerge after building separate assemblies.
3) Well, in theory a single module could be included in multiple assemblies, but there'd be no point in doing so - it would create a very confusing system.
4) I'm not really sure what you mean. Visual Studio creates some intermediate files in the obj directory, if that's what you mean. The command line compiler doesn't leave any extra files lying around, but it may create intermediate files which it deletes on completion - I don't really know.
EDIT: I don't believe VS builds modules as an intermediate step. Compiling in Visual Studio always creates a single assembly per project, and that assembly has a single module. When you say that CLR via C# says that "modules can span assemblies" are you sure you don't mean that assemblies can span multiple modules? You can download modules of an assembly on demand, but not the other way round. If you have a specific reference, I could look it up...

You cannot create modules using VS, but you can do it using compiler. Modules are separate files on the file system, it is possible to have several modules in one assembly written in different languages.
EDIT: Also you can put rarely used classes in the separate modules. Such modules will be loaded only when classes are needed.

.Net Add-ins and versioning

Our media center add-in is shipped as a single DLL which lives in the GAC (mediabrowser.dll), we allow users to write extensions for our add-in by referencing our DLL and accessing the pre-defined extensibility points.
On load we search through a plug-in directory, load all the assemblies in the directory, search the assemblies for a type implementing IPlugin and execute initialiaztion routine on an instance of the plugin. I am aware that this is not the most robust design (for example: we may want to look at appdomain isolation for plugin later on) but it works alright now.
As it stands, this seems to be working fine, except for one big caveat.
When plugin writers compile their plugins the plugin references mediabrowser.dll with a specific version. Later on when we revise our dll (to fix bugs or add features) all addins that were written against earlier versions of mediabrowser.dll break.
I have thought of a few solutions to this problem (note the assembly is in the GAC):
Ship a publisher policy with with mediabrowser.dll that will redirect all earlier compatible versions of mediabrowser.dll to the current version (this must also live in the GAC).
Ship a separate assembly which contains all the fixed extension points and contracts, be extra prudent about changing this assembly, have plugin writers link against this assembly. (but still look at using publisher policies for non-breaking changes to the interfaces)
Let a third party worry about this stuff and leverage MEF or some other framework that takes care of this kind of stuff.
Hookup AppDomain.CurrentDomain.AssemblyResolve and resolve the earlier versions of the assembly to the current version. This will only work if the assembly of that specific version is not in the GAC.
Are there any other solutions to this problem that I am missing?
Update I ended up going with option 4.

I see you have picked an answer but if you are still open to ideas there is another option to consider (the very one used by the .NET framework): do not increment your assembly version between builds (but do increment your assembly build number).
This will allow your assembly to retain it's same strong name, not breaking plugin compat, and still allow you to distinguish builds from each other (using the assembly build number).
You can see this in action in .NET 2.0 through 3.5. Those releases all use the assembly version 2.0.50727 but have distinct build versions.
As long as you do not break your interface contracts (which you should never do anyway) this approach is quite reasonable.