Vacature “Microsoft Technisch consultant” bij Nokavision

Het bedrijf Nokavision uit ‘s-Hertogenbosch heeft een interessante vacature beschikbaar. Ben je op zoek naar een nieuwe uitdaging in het zuidelijke deel van Nederland, lees dan de beschrijving eens door.

!cid_image001_gif@01CB7CF2

Ik ken Nokavision als een bedrijf dat graag bezig is met nieuwe Microsoft technologien. Ze hebben een sterk verleden met document management en document stromen en business process management in organisaties. Om meer te weten te komen over Nokavision, kun je natuurlijk hun website bezoeken. Daar vind je onder andere case studies van eerdere klanten, hun producten (o.a. Skelta, StreamServe en Captaris producten) en de diensten die ze bieden.

Hieronder de vacaturetekst. Ben je geinteresseerd, neem dan contact op met Rob Steenvoorden. De contactgegevens staan onderaan.

Microsoft Technisch consultant

Doel van functie

Als Consultant maak je deel uit van een professioneel team dat als standplaats Den Bosch heeft. Onze werkzaamheden vinden plaats aan oplossingen die als product in de markt worden gezet. Je werkt aan de ontwikkeling, uitbreiding en beheer van Microsoft oplossingen. Je werkt met professionele collega’s met diverse ideeën, achtergronden en werkwijzen. Je wordt aangemoedigd je technische vaardigheden uit te breiden en je thuis te voelen in een “lerende” cultuur.

Verantwoordelijkheden en taken

Je bent verantwoordelijk voor de ontwikkeling, oplevering en onderhoud van nieuwe en bestaande  producten op basis van Microsoft technologieën. Je werkt met de modernste Microsoft technologieën waaronder C#, .NET 4, Silverlight 4, WCF RIA Services, Entity Framework, Enterprise Library, SQL Server. Tevens maken we gebruik van Workflow technologie die .NET gerelateerd is.

Ideale profiel

  • Ervaring met C# en .NET
  • Junior/Medior software ontwikkelaar
  • Je bent accuraat en hebt een actieve houding
  • Belangstelling voor complexe bedrijfskundige en technische omgevingen
  • Gewend om volgens methodieken te werken

Een pré is:

  • Kennis van UML & Design Patterns
  • Kennis van en ervaring met Silverlight en/of WPF

Arbeidsvoorwaarden

Nokavision is een zeer sociaal bedrijf. Nokavision biedt uitstekende primaire/secundaire arbeidsvoorwaarden. De opleidingsmogelijkheden zowel intern als extern zijn uitstekend. Daarnaast besteden wij veel tijd en energie aan persoonlijke groei en ontwikkeling.

Wil je meer weten of reageren: stuur je bericht met CV naar r.steenvoorden@nokavision.com of bel met 073-6408490.

Posted in Uncategorized | Leave a comment

Two exam opportunities

Quick post on two beta Microsoft exams that you are allowed to participate in. Gerry o’Brien posted that the exams:

are now available to take. The beauty is that if you manage to pass the qualifying score on the beta exam, you also pass the exam as soon as it is released. Of course, it is also a good challenge for your brain and a test of your knowledge on the topic of the exam. When you’re into the business of training, coaching or other knowledge transfer areas, this is a great opportunity to find out which training, books and e-learning material is needed to prepare for this exam.

The Microsoft Learning website lists extra information on the exams 70-583 and 70-506. The exams seem to be the one exam to pass to acquire either the “MCPD: Windows Azure Developer 4” or “MCTS: Silverlight 4, Development” certifications.

You can take these exams for free if you use the promotion codes AZPRO and SL410 respectively. You need to enter these code at the Payment Information screen.

image

Time is limited, so be sure to register immediately at Prometric.

Posted in Uncategorized | Leave a comment

Microsoft Most Valuable Professional for 2010

MVPLogoYesterday I received mail from Toby Richards with the title “Congratulations 2010 Microsoft MVP!”. This means that Microsoft grants me this title as a Microsoft community contributor for another year.

The mail is pretty flattering: “This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others.” I do hope people like the presentations I give at the various Dutch conferences. That’s my main place to share.

Thanks Microsoft. Thanks community. Hope to meet you again soon.

Posted in Uncategorized | Leave a comment

Extracting files from an MSI package

Reminder to self, as I have searched for this too many times:

How to extract files from an MSI file without actually installing it:

msiexec /a c:downloadsWCFRestStarterKit.msi /qb TARGETDIR=c:RESTStarterKit

Run this from an elevated command prompt. The target directory does not have to be created beforehand.

Posted in Uncategorized | Leave a comment

Testing from Word

Message request = Message.CreateMessage(MessageVersion.None, “Status”);

SampleProfileUdpBinding binding = new SampleProfileUdpBinding();

binding.ReliableSessionEnabled = false;

 

Posted in Uncategorized | Leave a comment

WCF Extensibility part 5: Make your endpoints behave

In the previous post we looked at an operation behavior that applied the operation formatter to a particular operation description. Because this is default behavior for all operations in the interface defined, we will make life a little easier on us to have the operation behaviors applied automatically. A WCF endpoint consists of address, binding and contract. The latter is represented by the [ServiceContract] annotated interface, in our case IRcon and the target of our exercise.

image

The extensibility point that the WCF runtime provides is an endpoint behavior. Endpoint behaviors allow you to manipulate an endpoint’s definition. To create an endpoint behavior you need to implement the System.ServiceModel.Description.IEndpointBehavior interface:

public interface IEndpointBehavior
{
    void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters);
    void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime);
    void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher);
    void Validate(ServiceEndpoint endpoint);
}

This should look pretty familiar to you if you have read the previous part in this series. Again, you can apply your behavior both on the client and service side. There’s another validation moment in the Validate method and you can add binding parameters to the binding context for later use.

The implementation of ApplyClientBehavior is the most interesting one. Here we will apply the operation behavior to each of the endpoint’s operations.

public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
{
    if (endpoint.Binding is SourceRconTcpBinding)
    {
        foreach (OperationDescription description in endpoint.Contract.Operations)
        {
            ApplyFormatterBehavior(description, endpoint);
        }
    }
}

private void ApplyFormatterBehavior(OperationDescription operationDescription, ServiceEndpoint endpoint)
{
    if (operationDescription.Behaviors.Find<SourceRconOperationFormatterBehavior>() == null)
    {
        SourceRconOperationFormatterBehavior formatterBehavior = new SourceRconOperationFormatterBehavior();
        operationDescription.Behaviors.Add(formatterBehavior);
    }
}

Inside the implementation a simple loop over the operation descriptions in the contract is enough to get things going. The helper method ApplyFormatterBehavior makes sure that the SourceRconOperationFormatterBehavior behavior is applied only once.

An endpoint behavior needs to be added to the Behaviors collection of an endpoint to make it do its work. Given the client-side interface definition IRconProxy (which derives from both IRcon and IClientChannel) you can create a channel factory. The factory holds the the definition of the endpoint, provided by the implicit ABC in line 1 (address and binding are obvious, the generic <T> of the ChannelFactory represents the contract).

ChannelFactory<IRconProxy> factory = new ChannelFactory<IRconProxy>(binding, new EndpointAddress(uri));
factory.Endpoint.Behaviors.Add(new SourceRconEndpointBehavior());
factory.Open();

Line 2 adds the behavior to the Behaviors collection of the endpoint. When the factory opens, the behavior gets applied. The operation formatters get applied at that moment as well. The operation formatters are used when the actual calls through the channel are made.

Side note: if you were to use a ClientBase<T> derived proxy, you would need to drill down into the proxy.ChannelFactory.Endpoint.Behaviors to get at the Behaviors collection, or use the proxy.Endpoint property for easier access.

To summarize, an endpoint behavior allows you to manipulate your endpoint. Behaviors are an opt-in, so it is your choice whether to apply them or not.

Posted in Uncategorized | Leave a comment

WCF Extensibility part 4: Applying formatting to operations

In the previous part we inspected the way you can influence the transition from a service operation to a WCF Message object. This was accomplished with an implementation of the IClientMessageFormatter interface, in our case the SourceRconOperationFormatter class. Now it’s time to look at how to apply this message formatter to the client channel stack.

image

The message formatting happens based on the formatter that is specified as part of the description of an operation. This means that in theory you could change the formatter from operation to operation. In order to get the formatter in place you need to change the Formatter property of the System.ServiceModel.Description.OperationDescription for the operation of your choice. Obviously this has to be done before the first method call is made. The extensibility point that allows you define which formatters are used for client and service operations is an operation behavior. When applied an operation behavior will influence the way an operation behaves when called. Hence the name.

Operation behaviors must implement the System.ServiceModel.Decription.IOperationBehavior interface. First of all look at that interface definition:

public interface IOperationBehavior
{
    void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters);
    void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation);
    void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation);
    void Validate(OperationDescription operationDescription);
}

As you can see it has two methods to apply the specifics of your behavior to an operation description: one for client-side and one for service-side operations. We need to fill in the client-side proxy part of it only. Furthermore, the behavior can validate the operation to which it is applied. More on this in a moment. And finally, should the behavior need to add specific parameters to the entire binding (which can be accessed later on from the binding context) it is free to do so in the AddBindingParameters method.

The SourceRconOperationFormatterBehavior class explicitly implements the IOperationBehavior interface. There is no point to have public method as it is unlikely that the implementation will be called other than via the interface.

public class SourceRconOperationFormatterBehavior: IOperationBehavior
{
    #region IOperationBehavior Members

    void IOperationBehavior.AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters)
    {
        // Nothing for us to do
    }

    void IOperationBehavior.ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation)
    {
        // Apply our own formatter
        clientOperation.Formatter = new SourceRconOperationFormatter(operationDescription);

        // This behavior takes care of both request and replies at client
        clientOperation.SerializeRequest = true;
        clientOperation.DeserializeReply = true;
    }

    void IOperationBehavior.ApplyDispatchBehavior(OperationDescription operationDescription, System.ServiceModel.Dispatcher.DispatchOperation dispatchOperation)
    {
        // Client-side only
        throw new NotImplementedException();
    }

    void IOperationBehavior.Validate(OperationDescription operationDescription)
    {
        // Always valid?
        // In our case we cannot have ref or out parameters
        // We could check that parameters are primitive types
    }

    #endregion
}

The ApplyClientBehavior method set the Formatter property of the client operation to which the behavior is applied. It also expresses that the client operation will serialize and deserialize both request and reply messages.

Inside the Validate method we could check whether the operation is compatible with the behavior. For example, we should check that there are no ref or out parameters. We could check that the parameters are either representable as a string, and whether the return value is either of type string (the reply messages always contain string data) or that it is deserializable from a string. I have not been able to get the validate method to be triggered and all implementations of IOperationBehavior inside the framework have an empty method body. With Reflector you can see that the client validations on behaviors should go off when the ChannelFactory is opening. I’m not sure why it does not fire.

You can go the extra mile and have your behavior derive from Attribute:

[AttributeUsage(AttributeTargets.Method)]
public sealed class SourceRconOperationFormatterBehaviorAttribute : Attribute, IOperationBehavior

so it can be used as an attribute above a method:

[ServiceContract]
public interface IRcon
{
    [OperationContract(Action = "status")]
    [SourceRconOperationFormatterBehavior]
    string GetStatus();

You would probably want to change the name of the behavior/attribute class to something like SourceRconOperationAttribute so it looks like [SourceRconOperation]. This makes more sense. In our case the behavior is not really optional as we need to apply the operation formatter for every operation in a service contract to make things work. Having an interface that is only partially usable for remote control seems weird.

Having made the remarks above on how behaviors are non-optional, the next topic will be about a streamlined way to accomplish that all operations in a service contract will have the operation formatter behavior applied.

Posted in Uncategorized | Leave a comment