The default behavior of WCF services is to expose schemas in the service metadata of the object data graph that is exposed in the service contract.
When consuming the metadata, the default behavior is very similar in the sense that it creates the object data graph that is exposed in the service contract.
In some cases you may want to publish additional data as part of the service metadata even though it isn’t referenced somewhere in the service contract, that is other than the fault contracts, parameters object graph, and the return values.
How can we do that then?
First, I searched in Google and came across this article which provides a way to do so, but I found it to be far from perfect because of the following reasons -
- It doesn’t provide a way to dynamically adding unreferenced known types
- It doesn’t support composite object graphs where one of the members could be of a type which is already exposed as part of the service metadata, an exception is thrown in this case
- It requires the client to use a behavior to get these data contracts, though there are ways to override this
The solution -
My goal was to use the 'ServiceKnownTypeAttribute’ to include additional data types which are unreferenced in the service metadata.
Unfortunately, when you do that, WCF ignores that type because it is unreferenced by the service and it isn’t generated on the client.
I found a workaround for this though, if you include the type ‘System.Object’ within the referenced data of your service, these additional types would actually be exposed and generated on the client side.
Obviously, I wouldn’t want to enforce the developer to include ‘System.Object’ anywhere in an explicit way such as adding a stub method, because that would basically suck a big time.
The workaround I chose to do was to inject a fault contract of type ‘System.Object’ on a single operation, this has the least impact on the service and would be pretty much hidden from the developers in both sides because it is more of a tagging metadata rather than API.
Doing that, I provide a solution that completes what I was aiming for -
I can define unreferenced data types for my service that may include existing types within them, I can use the dynamic form of the ‘ServiceKnownTypeAttribute’ to define these types dynamically, and it would be generated on the client side without the need for a special behavior on its side too.
It looks as the following -
First we need to add the service behavior which injects the fault contract automatically for us -
Code Snippet
- //The behavior that injects the fault contract
- host.Description.Behaviors.Add(new UnreferencedTypePublishingBehavior());
Then, we can use the ‘ServiceKnownTypeAttribute’ to include whatever we like -
Code Snippet
- [ServiceContract]
- [ServiceKnownType(typeof(CommonStatusCode))]
- //[ServiceKnownType("GetKnownTypes", typeof(Helper))]
- interface IMyService
- {
- [OperationContract]
- ActionResult DoJob();
-
- [OperationContract]
- ActionResult DoJobWithNewVersionEnum();
- }
That’s it, when the client consumes the metadata, the ‘CommonStatusCode’ would be included in his service reference.
A real-life example
You might wonder where you would need such a thing.
A valuable example would be to use Enum with service versioning in mind to support backward compatibility.
Enum is pretty problematic in terms of service versioning, read here.
Basically, if you change its members, it is considered to be a breaking change because that would blow up existing clients when they would try to deserialize the data with the new value.
As the code sample shows, you can use this approach for using Enum in a way that it would be more fair to service versioning.
Typically, you can use an integer as the value to be transferred but expose the Enum as the additional unreferenced data type.
That way clients can match the integer with the generated Enum and map non-existing data as a default member that represents such cases.
I welcome you to check the code example to get a complete notion of this approach.
Where’s the code?
You can download the code if you like.
You may find the need to determine the request and reply message size when calling a service operation.
It can be for logging purposes, or a practical one such as deciding whether you need to compress the data or not.
The key component in WCF that knows about the actual size of the message is the message encoder, and of course, you can plug-in your own encoder as part of WCF’s extensibility point. Ahhh, got to love this framework!
Lets examine the feature requirements first -
- We need to have a way to get the incoming message size in our service implementation.
- We need a way to enable the client to get the reply message size.
You can download the code here.
Basically, in order to implement a message encoder and to plug it in, you need to implement your own MessageEncoder, MessageEncoderFactory, and MessageEncodingBindingElement.
Additionally, since this is part of the binding elements, we need to plug it in as part of the binding.
The implementation is fairly simple, since all I did was wrap the existing ones and added my message headers in the proper place.
I will not show this code here, it’s pretty straight forward, I recommend you just download the code and take a look at it.
Finally, I implemented a behavior that you can attach to your service which does all the heavy lifting for you.
It actually switches the current binding with a wrapper binding that plugs in our custom message encoder, pretty sweet.
In conclusion, here’s how our service would look like:
Code Snippet
- [OperationMessageSizeBehavior]
- public class MyService : IMyService
- {
- public void Do(Foo foo)
- {
- Console.WriteLine("MyService.Do() - Incoming request size: {0}KB",
- OperationMessageSizeExtension.Current.SizeInBytes / 1024);
- }
- }
As you can see the usage is very simple.
You define the behavior on your service, then you can access the extension to retrieve the size of the incoming request and do whatever you want with it.
One more tip – Keep the meta-data aligned:
I thought I should share a problem I experienced when I coded this – everything looked fine and it all worked.
However, when a developer tried to add a service reference against the service meta-data, he would get an incorrect binding.
I was wondering why it happened, my wrappers were delegating every single operation to the existing ones, so what was I missing?
Ahhhh.. Of course! Don’t forget about the ‘IWsdlExportExtension’ and ‘IPolicyExportExtension.
Encoding binding elements could be implementing those interfaces to participate in the building of the service meta-data.
I fixed the problem by implementing these interfaces myself and forward it to the existing binding element if it too has implemented it.
This post discusses several questions:
- Should ‘PerCall’ services care about the concurrency mode?
- Can closing the channel block after calling O/W operation?
- Should you reuse the same proxy instance concurrently?
- Does the Async Pattern matter in concurrent client?
This is quite a long post, but it should be quite interesting 
, you should download the example here.
In order to discuss the matter, let’s establish the scenarios we’re going to test first:
About the contract:
Code Snippet
- [ServiceContract]
- interface IMyService
- {
- [OperationContract]
- void Do();
-
- [OperationContract(IsOneWay = true)]
- void DoOW();
- }
About the service:
- The implementation of the service doesn’t matter, let’s make it simulate work using Thread.Sleep for 5 seconds.
- The service is configured as PerCall
About the binding:
About the client:
- The client works with a contract with the addition of the asynchronous pattern operations (Begin/End)
- The client makes 2 concurrent requests to the service on the same channel using a certain invocation mode. (see further down)
- It closes the channel once both calls are completed
About the invocation modes:
The findings vary according to how you call the service.
Let’s define 4 modes – RequestReply, RequestReplyAsync, OneWay, OneWayAsyncPattrn.
Typically, the implementation describes it pretty straightforward -
Code Snippet
- static Task GenerateTask(IMyServiceExtended channel, CallMode callMode)
- {
- switch (callMode)
- {
- case CallMode.RequestReply:
- return Task.Factory.StartNew(channel.Do);
-
- case CallMode.RequestReplyAsyncPattern:
- return Task.Factory.FromAsync(channel.BeginDo, channel.EndDo, null);
-
- case CallMode.OneWay:
- return Task.Factory.StartNew(channel.DoOW);
-
- case CallMode.OneWayAsyncPattern:
- return Task.Factory.FromAsync(channel.BeginDoOW, channel.EndDoOW, null);
-
- default:
- throw new NotSupportedException();
- }
- }
Inspected scenarios:
The variations for the scenarios are made with every combination of the service concurrency level and invocation mode.
That’s it, so how about some answers?
Note – I suggest you download the example and see the scenarios in action.
First of all, some of the findings occur due to the selection of the binding.
NetTcpBinding creates a duplex session channel shape by nature, it doesn’t matter if the service is PerSession or not, that is why other bindings might result with different behavior.
Q: Should ‘PerCall’ services care about concurrency?
In Short: Yes!
The ConcurrencyMode is often described as a concurrency control in the access to the service instance.
If that was the case, PerCall services shouldn’t behave differently according to the ‘ConcurrencyMode’ you set on it, since every call gets a dedicated instance.
So, is that the case? No
Try using the ‘OneWay’ invocation mode and see the differences between concurrency mode ‘Single’ and ‘Multiple’.
- Using ‘Single’ ends up with the two calls being invoked sequentially on the service side, causing the channel to be closed after 10 seconds.
- Using ‘Multiple’ ends up with the two calls being invoked concurrently on the service side, the channel is then closed after 5 seconds.
There we go, using this scenario we see that you should consider setting the concurrency mode of your services, even if it’s PerCall.
Another thing to note here is that closing the operation can block, as we see here, and can throw exceptions too.
Q: Can closing the channel block after calling O/W operation?
As seen in the same scenario as above – Yes!
Due to the session-ful duplex channel shape the NetTcpBinding creates, closing the channel waits for the operation to be completed to gracefully terminate the connection.
Another tip here is you can use the OneWayBindingElement which basically removes the session-bound channel shape, and then you can close it without waiting for the O/W operation to complete.
Q: Does the Async Pattern matter in concurrent client?
In Short: Yes!
Try setting the ConcurrencyMode to Multiple and examine the difference between the invocation mode ‘RequestReply’ and ‘RequestReplyAsyncPattern’,
When calling a R/R operation in its synchronous form from concurrent environments, it isn’t really dispatched concurrently on the service.
Actually, it is being dispatched sequentially one after another.
Oddly enough, if you use the asynchronous pattern invocation, it is dispatched concurrently on the service side!
Q: Should you reuse the same proxy instance in a concurrent environment?
In Short: It Depends
First of all, ‘PerSession’ or Duplex services are out of the question in this case, as they may require a specific design of using them.
As you can see from the example above, when using the same proxy instance concurrently, it doesn’t assure you it is actually processed concurrently on the service.
This basically means that concurrent calls can be queued up and cause a bottleneck and eventually blow up entirely.
Additionally, various tests we made at several customers showed that even if you manage to configure it as efficient as possible, where everything is being processed concurrently at both ends, intensive use of the same channel concurrently can cause an overload and turn the performance to the worse.
The above basically indicates that you shouldn’t use the same instance concurrently.
However, you might find that using the same channel gets you better performance at specific loads, especially if you build infrastructure to separate the processing layer from the WCF runtime.
To conclude the matter, you should assess the expected load and choose the right approach for your needs.
Boy that MS-DTC, huh? 
It can give much trouble, no doubt.
If you can’t communicate between two parties and keep failing with errors such as “The flowed transaction could not be unmarshaled”, try the following:
- Use DNS instead of IP addresses
- Disable Firewall
- Remove security and enable the options in the MS-DTC security (in the Component Services shell)
- Try DTCPing to troubleshoot the case
If everything seems to be set properly and you’re still experiencing connectivity issues, you should try reinstalling MS-DTC.
This is specifically necessary if the OS was created from an image, the MS-DTC relies on a unique ID, and if you use the same image, this could cause the problems.
I strongly recommend you follow these instructions for removing MS-DTC and reinstalling it. In some cases, I had to do this complete wipe and install to solve the case.
Good luck.
I assume you have heard about the great addition in .NET 4.5 – The Async Keyword.
It is truly one of the key changes made to the .NET language, and it is awesome.
Asynchrony should be part of our code, there’s no escape from that.
- If you write UI applications – you need asynchrony to avoid blocking the UI thread.
- If you make I/O operations – you should use its asynchronous model that utilizes the I/O completion threads instead of occupying a worker thread.
- If you build a service – you may want to implement the service using the asynchronous approach if you’re doing mainly I/O work.
- If you want to parallelize your code – you may want to use the TPL and invoke operations asynchronously and in parallel.
- And more..
Prior to .NET 4.5, the code looks quite awful in terms of all the nested lambda expressions, error handling, and the use of the synchronization context.
It was also easy to make mistakes writing in this fairly complex paradigm, but I guess it comes down to the developer’s maturity and habits. I specifically got quite used to that by now, so it is all readable to me 
.
In .NET 4.5, Microsoft introduced us with the new ‘async’ and the ‘await’ keywords.
The goal of this post isn’t to explain what it does, there are enough resources out there already that you can follow up on if you like to catch up.
I would like to discuss a specific feature of the ‘await’ keyword, which is continuing the execution on the captured synchronization context.
When you write the following code -
Code Snippet
- async void Do()
- {
- Console.WriteLine("Thread Id: {0}", Thread.CurrentThread.ManagedThreadId);
-
- await DoSomethingAsync();
-
- Console.WriteLine("Thread Id: {0}", Thread.CurrentThread.ManagedThreadId);
- }
-
- private Task DoSomethingAsync()
- {
- return Task.Run(() =>
- {
- Thread.Sleep(1000);
-
- Console.WriteLine("Thread Id: {0}", Thread.CurrentThread.ManagedThreadId);
- });
- }
Q: What would be printed in line 7? Would it be the same as in line 3?
That’s a trick question
Using the ‘await’ keyword at its default form results in the continuation to be posted to the synchronization context available before beginning the asynchronous work.
This means that the output of line 7 relies on the implementation of the synchronization context.
If you’re inside a WPF application, the DispatcherSynchronizationContext will post it to the same thread, so line 7 would end up printing the same Id as in line 3.
However, if you’re in environment where there isn’t such synchronization implementation, such as the default .NET ‘SynchronizationContext’ which simply queues the work to the thread pool, you should end up with something else.
This question was just for fun though, the key thing I wanted to emphasize is -
Posting the continuation to the captured synchronization context is wasteful in case you don’t care about it.
That is especially true if you’re in a UI application, where the continuations are made on the UI thread, and you may not even need access to UI resources at all.
Furthermore, even in case your code executes inside a synchronization implementation where it just queues it to the thread pool, there’s still some performance hit, and though it is fairly minimal, if you can modify your code to be context agnostic and basically work as efficient as possible, you should do it.
In conclusion, in case you don’t care about the synchronization context, you should use the ‘ConfigureAwait’ method on the await and switch it off.
The above code could be fixed as following – (The change is at line 5)
Code Snippet
- async void Do()
- {
- Console.WriteLine("Thread Id: {0}", Thread.CurrentThread.ManagedThreadId);
-
- await DoSomethingAsync().ConfigureAwait(false);
-
- Console.WriteLine("Thread Id: {0}", Thread.CurrentThread.ManagedThreadId);
- }
-
- private Task DoSomethingAsync()
- {
- return Task.Run(() =>
- {
- Thread.Sleep(1000);
-
- Console.WriteLine("Thread Id: {0}", Thread.CurrentThread.ManagedThreadId);
- });
- }
There’s a demo project if you like to download.
Just make sure you use the WPF application in case you wish to see that the thread ID is the same as line 3 when not switching the feature off.
If you happened to implement an ‘ICommand’ for your presentation logic in WPF, and decided to contain PRISM’s DelegateCommand within your class and use its own mechanism of the ‘CanExecuteChanged’ event – Beware!
Consider the following example -
class CommandWrapper : ICommand
{
private readonly DelegateCommand _command;
public CommandWrapper(Action execute, Func<bool> canExecute)
{
_command = new DelegateCommand(execute, canExecute);
}
public bool CanExecute(object parameter)
{
return _command.CanExecute(parameter);
}
public void Execute(object parameter)
{
_command.Execute(parameter);
}
public void RaiseCanExecuteChanged()
{
_command.RaiseCanExecuteChanged();
}
public event EventHandler CanExecuteChanged
{
add { _command.CanExecuteChanged += value; }
remove { _command.CanExecuteChanged -= value; }
}
}
.NET 4.5 isn’t compatible with this approach! (With wrappers to any ICommand implementation)
If you upgrade to .NET 4.5, you will see that the UI doesn’t respond in case you raise the ‘CanExecuteChanged’ event in this scenario.
There’s actually an opened support ticket on that -
Backward Compatibility Problem in .NET 4.5: WPF / ICommand sender / WeakEventManager
I fixed it in our products by simply inheriting from DelegateCommand, instead of containing it.
You can download a sample project which demonstrates the problem. You can see it happens when the project is compiled to .NET 4.0 or 4,5, but it is actually working well when it is compiled to .NET 3.5.
Update: Luckily Microsoft identified it as a bug and provided a global update that fixes this issue and many others.
Yes, I am aware I didn’t post anything for a long time, sorry about that.
I can try and excuse myself by saying that I had plenty on my hands, including bringing my house together, raising a new baby girl, and much more.. but I won’t 
Putting everything aside, I plan to get right back on the horse and start posting some interesting stuff real soon, so stay tuned!
Expert Days is an annual software development conference held by E4D in Israel. This year, for the first time, some of CodeValue’s experts have joined forces with E4D and are participating in order to give you, the attendee, the best possible value. If you are a software developer, software architect, team leader or somehow interested in the hottest available Microsoft technologies – this is definitely the conference you want to be at.
The conference is held on 10/07/2011-14/07/2011, and there are dozens of one-day workshops, which are packed with practical knowledge which you can immediately use. Investing your time in these workshops will certainly payoff immediately!
For more information regarding the available workshops, feel free to click the banner below.
Among all of the conference’s experts, you can also find me there this year and I gladly invite you to participate in my workshop – Developing .NET Systems in Real-Life. Note that if you specify that you arrived through me and specify my instructor code (121) you can get a 20% discount to my workshop!
Except for my workshop, I personally recommend arriving at workshops performed by some of the other CodeValue experts – Alon Fliess, Eran Stiller, Eli Arbel, Josh Reuben & Shay Friedman.
But wait – there’s more!
This year, Expert Days has a free opening event on 10/07/2011. This event includes a cocktail party, mingling and a series of professional lectures all of which are absolutely free. During the opening event, an XBOX+Kinnect set will be given to one of the attendees. That’s right – an XBOX+Kinnect set shall be given away to one of you! All you have to do is register and show up…
See you there,
Amir
In one of our projects, we encountered odd exceptions that were thrown out of “GetExportedValue<T>” from the CompositionContainer of MEF.
There are 2 exceptions that I have seen that are related to the same issue:
System.InvalidOperationException: GetExportedValue cannot be called before prerequisite import 'MyType..ctor(Parameter="myParameter", ContractName="MyOtherType")' has been set
System.ArgumentException: An item with the same key has already been added.
After digging into the matter, we found that these errors occurred while trying to call GetExportedValue concurrently from numerous threads.
Yeah, simple as that, MEF isn’t thread-safe in its default form.
Following is a sample code which demonstrates the error -
Code Snippet
- interface IFoo { }
-
- [Export(typeof(IFoo))]
- [PartCreationPolicy(CreationPolicy.Shared)]
- class Foo : IFoo { }
Code Snippet
- var catalog = new AssemblyCatalog(typeof(Program).Assembly);
-
- CompositionContainer container = new CompositionContainer(catalog);
-
- List<Task> tasks = new List<Task>();
- for (int i = 0; i < 5; i++)
- {
- tasks.Add(Task.Factory.StartNew(() => container.GetExportedValue<IFoo>()));
- }
-
- try
- {
- Task.WaitAll(tasks.ToArray());
-
- Console.WriteLine("No errors, thread safe");
- }
- catch (AggregateException ex)
- {
- Console.WriteLine("Error occurred: {0}", ex.InnerException.ToString());
- }
In this example, “Task.WaitAll” would throw an exception because of the concurrent hit on GetExportedValue.
How to fix this -
Well, the fix is as easy as it can be. You need to construct the container as thread safe -
Code Snippet
- CompositionContainer container = new CompositionContainer(catalog, true);
In the second parameter we pass ‘true’ to make it thread-safe.
That’s it! dead easy.
You should note that it has a performance hit though, obviously.
I decided to blog alittle about my ongoing experience here in TechEd Eilat.
Yesterday, on day 1, I arrived to Eilat and immediately got the great atmosphere this conference has put out for us.
Day 1
I attended the evening key-note session and was very impressed by the operation the Microsoft has gathered and pulled it off beautifully. It wasn't hard to see that there was a great investment in this conference, and I'm simply glad.
The key-note was refreshing with good entertainment. There wasn't much that came new to me, but it was certainly nice to see how Microsoft sees the next generation in a new world of sharing and collaboration being materialized.
Day 2
I attended 2 sessions - Windows Azure Guidance Part 1 and 2. I liked these presentations very much, they met my expectations perfectly.
There wasn't any code, as much as I love to see code in sessions, that's what I expected. The presenter talked about all the key components in Windows Azure, explaining about them and how you should generally use them. That's what I was aiming for, just to get a bit more organized about things, and these sessions did just that.
Another session that I attended today was Deep Dive on Workflow Services. It was rather disappointing, don't get me wrong, the session was interesting and well built but I was expecting a more of a deep dive than what was actually there.
All in all, so far I'm having a blast. Soon there's the big party and I'm sure it would be great.
For day 3, I plan to go see the tooling presentation made by Alon Fliess, the CTO of our new company. I'm pretty sure I'll recognize everything there, but knowing Alon, this will be very professional and amusing to watch.
Another session that I plan to attend is about storage in Azure, I guess it'll be good too.
To summarize, the TechEd met my expectations in terms of content sessions and the execution of everything around it had been fabulous up until now. Microsoft - good job! thank you.
With the emerging of cloud computing, our perception of software design needs to shift and take account for the affects we need to deal with.
The signs are clear, with investments of billions of dollars by leading companies, such as Microsoft, Google, Amazon - Cloud computing is the future of the IT industry and many other specific product companies that can leverage its benefits.
If you looked into it, you must know by now – the pricing models for hosting applications in the cloud varies and you can choose from different packages to meet the requirements of your specific application.
How do you choose the right one? Well, that isn’t a simple question and it very much depends on the characteristics of your application.
Does it have enormous data behind it? Is it mostly data-centric with a lot of transactions? How busy is the front-end? How many cores would you need? Do you expect different request peaks at different times? And the list goes on..
Developing for the cloud requires good architecture if you want to leverage its true powers.
While there's a general architecture on how to program things in order to gain good practices, such as scalability, good performance and fault tolerance, this
post is written specifically to present the Cost-Oriented Development and Architecture approach as a
new relevant concept.
This subject no short and simple, in future posts I plan to include technical examples, best
practices and design principles as well.
Why should you care?
In most companies, the hardware is purchased and deployed to support the expected traffic and requirements and the applications are developed with no unique thought to address the cost-related circumstances.
This approach should change. With cloud computing, the operating system and hardware is ready for you in an environment where you essentially pay-per-use for the resources you utilize. (May vary according to the specific pricing package you purchased)
In such world, inefficient code and resource-utilization should be your concern! This has a much more direct affect, inefficient code means less money in your pocket.
To clarify, inefficient in that sense stands for cost-inefficiency, thus the term – Cost-Oriented Development.
Cost-inefficiency can obviously stand for performance-based issues, but also simple yet unaware mistakes of resource utilization or bad practices when it comes to cloud development.
Product companies which want to be cost-optimized, need to understand the implications of the code in terms of how it can affect the hosting price.
You can see some examples in the following article - Windows Azure: Cost Architecting for Windows Azure
When developing for the cloud – there is no such thing as “cheap developers”, this can end up costing you a lot of money down the road, unless you plan to invest in code review, guidance, and perhaps seeking for consult.
So what next?
This is the main aspect my new company assists with and this is only the beginning.
CloudValue is a Cost-Oriented Development solution company. We provide tools & methodologies for cost optimized applications targeting the new Cloud platforms, and essentially help you to save a lot of money.
In addition to providing professional services all around, our leading product, Cloudoscope™, the first Cost-Profiler ever, will help you write cost-optimized code and provide you with the ability to review your code, statically or dynamically, to predict problematic spots, inspect actual cost-value of every request and generally help you understand exactly what you are paying for and how you can make it even better.
Enough with the teasers, read more about us – CloudValue
I’d like to thank Michal and Microsoft for sending me to the TechEd in Eilat next week.
There are some presentations which seem cool and I’m happy to get the chance to hear them out in person.
I plan to blog about interesting sessions, so tune in if you like.
There was a project that I assisted with the WCF communications where they needed to allow the client to specify different credentials without being dependent on the windows account.
The first thing that comes into mind is to use the UserNameToken technique to pass in the client credentials. The design instructed to use TCP as the transport and not use message security. Obviously, this technique has privacy and integrity issues where there isn’t any encryption nor signing, but that was their decision because it wasn’t an issue in the purpose of the project.
Well, this setting isn’t as trivial as you would expect.
The default form of the NetTcpBinding allows you to use UserNameToken only as part of message security and forces you to use a certificate to enable that message security.
I ended up setting them a CustomBinding which provides the scenario they needed.
Service Side
Configuring the Service Host -
Code Snippet
- _host = new ServiceHost(typeof(Service));
- _host.AddServiceEndpoint(typeof(IService), Config.ServiceBinding, Config.ServiceAddress.Uri.AbsoluteUri);
-
- _host.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = UserNamePasswordValidationMode.Custom;
- _host.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = new CustomUserNameTokenValidator();
-
- _host.Open();
Custom Simple Validator (you can write any logic you need here) -
Code Snippet
- class CustomUserNameTokenValidator : UserNamePasswordValidator
- {
- public override void Validate(string userName, string password)
- {
- Console.WriteLine("CustomUserNameTokenValidator.Validate - {0} / {1}", userName, password);
-
- if (string.IsNullOrEmpty(userName))
- {
- throw new SecurityTokenValidationException("Invalid username");
- }
- }
- }
In the service code, you can extract the caller’s identity name as follows -
Code Snippet
- class Service : IService
- {
- public void Do()
- {
- Console.WriteLine("Service.Do() - Identity Name: {0}",
- ServiceSecurityContext.Current.PrimaryIdentity.Name);
- }
- }
Client Side
In the client side you need to use the same binding, provide the UserNameToken credentials and simply call the service -
Code Snippet
- ChannelFactory<IService> factory = new ChannelFactory<IService>(Config.ServiceBinding, Config.ServiceAddress);
- factory.Credentials.UserName.UserName = "myUser";
- factory.Credentials.UserName.Password = "myPassword";
-
- IService proxy = factory.CreateChannel();
-
- proxy.Do();
-
- ((ICommunicationObject)proxy).Close();
Configuration
Following is the CustomBinding which enables this scenario -
Code Snippet
- SecurityBindingElement securityElement = SecurityBindingElement.CreateUserNameOverTransportBindingElement();
- ((TransportSecurityBindingElement)securityElement).AllowInsecureTransport = true;
-
- _serviceBinding = new CustomBinding(new BindingElement[] {
- securityElement,
- new BinaryMessageEncodingBindingElement(),
- new TcpTransportBindingElement()
- });
Feel free to download the source code and see that in action.
As part of the task where I had to upgrade an existing WPF project to PRISM 4.0 and work with MEF, one of the requirements was to support registering existing non-attributed parts.
Consider the following example -
Code Snippet
- public interface IFoo { }
-
- public class Foo : IFoo { }
-
- static void Main(string[] args)
- {
- //This is the desired thing to do
- myCatalog.Register<IFoo, Foo>();
- }
As you can see, type Foo has no export definitions set on it.
One approach would be to go over all the registrations and add attributes where needed, or create wrappers for legacy components, but the goal in our case was to support this kind of registration.
After digging around, I found two ways that you can go about it -
- Implement a conventional catalog using the ReflectionModelServices which is the MEF’s API for building reflection related parts information.
- Example - CodePaste.NET - A conventional catalog for MEF (Prototype)
- Use the MEF’s AttributedModelServices with a TypeDelegator to expose the actual type as an attributed type even though it doesn’t have attributes defined directly on it.
This is quite a sophisticated solution and I decided to stick with that one. - Example - Poco, Mef, and custom type systems. Are you ready to take the red pill
You can look at the links to see the actual code of each solution. Plus, you can integrate it with the type catalog which supports type registration in runtime which I described in my previous post.
Recently, I dug deep into MEF because I was involved in a project where there was a decision to upgrade the WPF client to PRISM 4 and advance to using MEF alone instead of Unity.
While many argue that MEF isn’t yet a full DI framework, it still provides an easy way to enable application extensibility in your projects.
One of the tasks that I had while upgrading the client to PRISM 4, is to keep supporting type registration in runtime, something in the sort of the following -
Code Snippet
- public interface IFoo
- {
- }
-
- [Export(typeof(IFoo))]
- public class Foo : IFoo
- {
- }
-
- catalog.Register<Bar>();
The built-in TypeCatalog that comes with MEF requires you to specify the types in the constructor and there is no support for registrations in runtime for the same catalog.
In order to support this feature, I could simply add a new TypeCatalog for every registration request in runtime with the desired type, but that seemed to be kind of wasteful.
MEF does support catalog changes in runtime, you need to implement ‘INotifyComposablePartCatalogChanged’.
The solution
I implemented a type catalog that supports registrations in runtime, here is the core implementation -
Code Snippet
- public void Register(IEnumerable<Type> types)
- {
- if (types != null)
- {
- List<ComposablePartDefinition> addedParts = new List<ComposablePartDefinition>();
-
- foreach (Type type in types)
- {
- ComposablePartDefinition part = AttributedModelServices.CreatePartDefinition(type, null);
-
- addedParts.Add(part);
- }
-
- using (var atomicComposition = new AtomicComposition())
- {
- OnChanging(new ComposablePartCatalogChangeEventArgs(addedParts, EmptyPartDefinitions, atomicComposition));
-
- _lock.EnterWriteLock();
- try
- {
- foreach (var addedPart in addedParts)
- {
- _parts.Add(addedPart);
- }
- }
- finally
- {
- _lock.ExitWriteLock();
- }
-
- atomicComposition.Complete();
- }
-
- OnChanged(new ComposablePartCatalogChangeEventArgs(addedParts, EmptyPartDefinitions, null));
- }
- }
If I need to register known types in runtime, I can just do the following -
Code Snippet
- RuntimeTypeCatalog catalog = new RuntimeTypeCatalog();
-
- CompositionContainer container = new CompositionContainer(catalog);
-
- catalog.Register<Bar>();
- catalog.Register<Foo>();
Feel free to download the full source code and see it in action.
More Posts
Next page »