Configuration configSystem = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
var bindingSection = BindingsSection.GetSection(configSystem);
string customConfig = "<netTcpBinding><binding name=\"netTcpBinding\" maxReceivedMessageSize=\"12345\" hostNameComparisonMode=\"Exact\" /></netTcpBinding>";
// another example: 
// string customConfig = "<binding name=\"basicHttpBinding\" messageEncoding=\"Mtom\" maxReceivedMessageSize=\"14000\" allowCookies=\"True\" /></basicHttpBinding>";
bindingSection.SectionInformation.SetRawXml(string.Format ("<bindings>{0}</bindings>",customConfig));
BindingCollectionElement bindingCollectionElement = null;
foreach (BindingCollectionElement bicoelem in bindingSection.BindingCollections)
{
    if (0 < bicoelem.ConfiguredBindings.Count)
    {
        bindingCollectionElement = bicoelem;
        break;
    }
}
var newBinding = (Binding)bindingCollectionElement.BindingType.Assembly.CreateInstance(bindingCollectionElement.BindingType.FullName);
IBindingConfigurationElement bEleEx = bindingCollectionElement.ConfiguredBindings[0];
bEleEx.ApplyConfiguration(newBinding);

At this point the newBinding is configured with the configurationoptions you added in the "customConfig" string.

HTH

    public interface ISomeService

    {

        void TestMethod();

    }

In order to use a type with policy injection it must derive from MarshalByRefObject:

    public class SomeService : MarshalByRefObject, ISomeService

    {       

        public SomeService() {}

        [PerformanceCounterCallHandler("EntLibPerfTest", "lta")]

        public void TestMethod()

        {

            Console.WriteLine(":-) Called my TestMethod"); //LOGIC

        }

    }

The parameters to the PerformanceCounterCallHandler attribute represents the performance counter category and instance name respectively. In order to allow PIAB to do its work you should retrieve the type through the static Create method on the PolicyInjection class (or Wrap it):

                SomeService s = PolicyInjection.Create<SomeService>();

MEF works with [Export] and [Import] attributes and will construct the registered export when a client asks for an implementation (according to the Creation Policy of course). Therefore it is not an option to export the type SomeService directly. Instead we create a Factory for the type that returns the type after applying registered policies for that type:

    public class SomeServiceFactory

    {       

        [Export(typeof(ISomeService))]       

        public ISomeService Instance       

        {               

            get               

            {

                //return new SomeService();

                return PolicyInjection.Create<SomeService>()

            }       

        }

    }

This solves the problem of delegating the construction to our Policy Injection Application Block, and you can simply write:

    class Program

    {

        static void Main(string[] args)

        {

            using (var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()))

            {

                using (var container = new CompositionContainer(catalog))

                {

                    ISomeService svc = container.GetExport<ISomeService>().Value; // wrapped

                    svc.TestMethod();

                }

            }

        }

    }

If we take a dependency in another class of this service as:

    [Export(typeof(MEFComposedType))]

    public class MEFComposedType

    {

        ISomeService _someservice;

        [ImportingConstructor]

        public MEFComposedType(ISomeService service)

        {

            _someservice = service;

        }

        public void Foo()

        {

            _someservice.TestMethod();

        }

    }

It will be created by our factory method and injected as expected:

    class Program

    {

        static void Main(string[] args)

        {

            using (var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()))

            {

                using (var container = new CompositionContainer(catalog))

                {

                    MEFComposedType mct = container.GetExportedValue<MEFComposedType>();

                    mct.Foo();

                }

            }

        }

    }

This will work fine for dependencies you can isolate, but if you rely on MEF to construct and compose more complex graphs of  types it may become necessary to use the static Wrap method of the PolicyInjection before using services.

Another way to accomplish almost the same is to export the actual type AND the interfaces and use the factory to add the policy:

    [Export]

    public class SomeService : MarshalByRefObject, ISomeService

    {

        [PerformanceCounterCallHandler("EntLibPerfTest", "lta")]

        public void TestMethod()

        {

            Console.WriteLine(":-) Called my TestMethod");

        }

    }

    public class SomeServiceFactory

    {

        SomeService _someservice;

        [ImportingConstructor]

        public SomeServiceFactory(SomeService someservice)

        {

            _someservice = someservice;

        }

        [Export(typeof(ISomeService))]

        public ISomeService Instance

        {

            get

            {

                return PolicyInjection.Wrap<SomeService>(_someservice);

            }

        }

    }

This method has the unfortunate side-effect of exporting actual types to the catalog, but solves the problem of using policy injection in complex graphs of dependencies. An alternative method could be interface inheritance. Having one public Interface that other components takes dependencies on and an internal interface deriving from this would allow for the usual flexibility.

https://msdn.microsoft.com/en-us/library/ff632023.aspx

and read Grigori's post here:

https://blogs.msdn.com/agile/archive/2010/04/20/microsoft-enterprise-library-5-0-released.aspx

Exerpt from landingpage:

Feature Builder is a Power Tool for Visual Studio 2010 (preview) which helps you easily create rich Visual Studio extensions. These extensions include tools (Visual Studio automation), code (your sample code or binaries you wish to share with others) and a map (a set of steps your users will want to follow to get the best experience with your extension). You can use this power tool to quickly package up sample code with custom menus, or take the time to create complete automated guidance experiences targeted toward a specific technology. You can share your extension with users by distributing a .vsix file, or posting to the Visual Studio Gallery.

Get the Book here - https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c09ffe4-43dd-4fcc-be35-c897c9bc4386
Code samples here - https://www.microsoft.com/downloads/details.aspx?familyid=33829BCF-F5EA-4650-B807-57C63A753753&displaylang=en

poc code?
Here you are (note I am using a custom RIA domain service to trim the list of modules)

    public class Bootstrapper : UnityBootstrapper
    {
        ModuleCatalog catalog = new ModuleCatalog();
        new public void Run()
        {
            AuthenticationContext ctx = new AuthenticationContext();
            EntityQuery<Module> query = ctx.GetModulesQuery();
            ctx.Load<Module>(query, loadOperation =>
                {
                    if (loadOperation.HasError)
                    {
                        throw new Exception("Not able to load catalog");
                    }
                    foreach (var item in ctx.Modules)
                    {
                        catalog.AddModule(new ModuleInfo()
                        {
                            InitializationMode = (InitializationMode)Enum.Parse(typeof(InitializationMode), item.InitializationMode, true),
                            ModuleName = item.Name,
                            ModuleType = item.TypeName,
                            Ref = item.Xap
                        });
                    }

                    base.Run();

                },null);
        }
        
        protected override DependencyObject CreateShell()
        {
            Shell shell = Container.Resolve<Shell>();
            Application.Current.RootVisual = shell;
            return shell;
        }

        protected override IModuleCatalog GetModuleCatalog()
        {
            return catalog;
        }
    }

Code to share typically include Presentation Models, Controllers, Domain Objects, Data Transfer Objects etc.

It is a good idea to start with the lowest denominator (Silverlight) if you have the choice from the beginning of your project. Some limitations may require you to think completely differently than you would normally if you were starting out with the full featureset of WPF (ex. ICommand) - you will eventually run into grayzones and I will leave it up to your judgement to decide when and how much you can/should share.

One way to achieve code file sharing is to use the "Add As Link" in the "Add Existing Item" dialog in Visual Studio (push the little arrow to get to it)

An example is shown below:

Notice the "link" icon on the "MyClass.cs" file in the Silverlight project.

If you have code that is not really shared but nice to keep in the shared file you can make use of the C# preprocessor directives. That sounds like a bad thing to do, but you may have to use different namespaces etc. Silverlight projects actually has a SILVERLIGHT "define" allowing you to include specific code simply by writing:

#if SILVERLIGHT
using System.Windows.Media.Animation;
#endif

You will notice that this is grayed out in the FullCLR project (and obviously the directive #if !SILVERLIGHT may be used in the opposite case)

I have just learned about another way of sharing source files that is less visible in the UI (no "linked icon") but seem to solve the exact same problem.

Any comments and other ideas are welcome - i acknowledge that it is kind of simple but it solves most cases where source code sharing is possible.