9 Comments

If you’re trying to use the NServiceBus.Host.exe in a x64 system, you may encounter the following exception:

Unhandled Exception: System.InvalidOperationException: No endpoint configuration found in scanned assemblies. This usually happens when NServiceBus fails to load your assembly contaning IConfigureThisEndpoint. Try specifying the type explicitly in the NServiceBus.Host.exe.config using the appsetting key: EndpointConfig...

To fix this, make sure that all your projects target the same platform (x64 / x86) as your NServiceBus.Host.exe.

In my case the server dll and the messages dll were build with the x86 switch and the NServiceBus.Host.exe was built with “any cpu”. This combination threw an exception as soon as I started the exe-file. Creating a configuration file for the host and defining the EndPointConfigurationType in it didn’t help. Changing the server dll to be build with “any cpu” didn’t help. But changing both the server dll and the messages dll to use the “any cpu” switch immediately fixed the problem.

3 Comments

VSS Binding Remover is a simple Windows software which removes the Visual Source Safe bindings from the Visual Studio projects and solutions. It has been tested with a VS2008 solution but it should work with VS2005 and VS2010 solutions also.  vssbindingremover

Credits

This program is mostly a copy-paste from the stackoverflow.Credits for the code goes to:

Usage

Start the VSSBindingRemover.exe, type in or select the root folder and hit Go. You should get a message box when processing has completed.

Note:You may need the elevated privileges if you have Windows Vista or Windows 7. This is because the program removes the read-only attributes from project files and solutions.

Download and source code

VSS Binding Remover is available at the GitHub. You can download both the source code and the executables from there.

0 Comments

NServiceBus uses log4net for its logging purposes. If you’ve run one the samples which are included with the NServiceBus package, you could be overwhelmed of all the logging that the NServiceBus.Host.exe prints to the console windows. If you’re just starting your journey with the NServiceBus, all the logging may make it hard to understand the samples, because there’s so much text. But, fortunately, it’s really easy to change the sample projects so that the Log4Net configuration is read from a configuration file. This way you can easily change how much log information is shown on the console windows.

The tutorial works with NServiceBus 2.0 RTM.


1. Modifying the source code

 

We’re going to change one of the NServiceBus samples so that a user can adjust the log4net logging through the configuration file.
Start by opening the FullDuplex-sample solution (located in nservicebus/samples/FullDuplex) –folder. You should see four projects:

  • MyClient
  • MyMessages
  • MyServer
  • MyServer.Tests

We’re going to change MyServer but this tutorial can be applied to the MyClient also. Open the MyServerEndpointConfig.cs and you should see this:

   1: public class ServerInit : IWantCustomInitialization
   2: {
   3:     public void Init()
   4:     {
   5:         Configure.Instance.RijndaelEncryptionService();
   6:     }
   7: }

We’re going to change two things. First, make the ServerInit-class to implement IWantCustomLogging. Then, add the following line in the Init-method:

NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);

So you should end up with a class like this:

   1: public class ServerInit : IWantCustomInitialization, IWantCustomLogging
   2: {
   3:     public void Init()
   4:     {
   5:         Configure.Instance.RijndaelEncryptionService();
   6:         NServiceBus.SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);
   7:     }
   8: }
If you now build the project and run it, you should see an error in the console output:

log4net:ERROR XmlConfigurator: Failed to find configuration section 'log4net'…

Lets fix this next.

2. Modifying the configuration file

We’re going to add a standard log4net section to the configuration file. This way you don’t have to recompile the project any more if you want to change how much log is shown in the console window.

First, locate the MyServer.dll.config –file. Then, in the configSections , add a new section for the log4net:

   1: <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net"/>

Then add the log4net configuration outside the configSections. Here’s a sample configuration which shows only INFO-messages (and higher) on the console:

   1: <log4net debug="false">
   2:   <appender name="console" type="log4net.Appender.ConsoleAppender">
   3:     <layout type="log4net.Layout.PatternLayout">
   4:       <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] &lt;%X{auth}&gt; - %m%n"/>
   5:     </layout>
   6:   </appender>
   7:   <root>
   8:     <level value="INFO"/>
   9:     <appender-ref ref="console"/>
  10:   </root>
  11: </log4net>
Save the configuration file and start the NServiceBus.Host.Exe. You should see much less log information.

Conclusion

It’s only a matter of two code changes to get the full control for your logging needs by making the NServiceBus.Host.exe to read the log4net configuration from the application’s configuration file.

Links

2 Comments

NServiceBus 2.0 RTM doesn’t contain a sample of how to use one of its nicest features: the distributor. By reading this blog post you will learn how to modify the FullDuplex-sample so that it uses the distributor model.

Background

NserviceBus’ documentation contains a good article about the logic behind the distributor. Here’s one part from the documentation which nicely sums it up:

You can think of the distributor as something like a load balancer - it distributes the messages coming to it to a number of other machines. This kind of physical one-to-many communication is needed for scaling out the number of machines running for a given subscriber, but doesn't actually entail any pub/sub. Each subscriber gets its own distributor and each of them decides independently to which machine it will pass its mesdistributorsages.

Here’s a small picture to light things up. As you can see, when using the distributor, the client doesn’t talk directly with the server but instead it communicates with the distributor. Distributor then forwards the received message to one of its workers. All workers can be located on the same server or every worker can have a dedicated server.

Aim of this post

We’re going to modify the FullDuplex-sample, which is included with the NServiceBus package, to use the distributor. In the end we’re going to have one client, one distributor and two workers all communicating with each other. And before we proceed, here’s a spoiler: We only need to touch the configuration files.

1. Configuring the distributor

You can locate the NServiceBus distributor from Nservicebusprocessesdistributor. Open the configuration file NServiceBus.Distributor.dll.config and then… you can close it. There’s nothing in there which we need to change! You can immediately start the NServiceBus distributor by starting the NServiceBus.Host.exe. Make sure you don’t see any error messages.

2. Configuring the client

Next, open the FullDuple-sample and then locate the MyClient-project and the contained configuration file App.config. In this step we actually have to modify the configuration file but it’s a simple change. By default the UnicastBusConfig looks like this:

<span style="color: #606060" id="lnum1">   1:</span> &lt;UnicastBusConfig&gt;

<span style="color: #606060" id="lnum2">   2:</span>   &lt;MessageEndpointMappings&gt;

<span style="color: #606060" id="lnum3">   3:</span>     &lt;add Messages=<span style="color: #006080">&quot;MyMessages&quot;</span> Endpoint=<span style="color: #006080">&quot;MyServerInputQueue&quot;</span> /&gt;

<span style="color: #606060" id="lnum4">   4:</span>   &lt;/MessageEndpointMappings&gt;

<span style="color: #606060" id="lnum5">   5:</span> &lt;/UnicastBusConfig&gt;

But like we’ve have learned, the client shouldn’t try to send the messages to the server (worker) but to the distributor. And to be specific, the messages should go to the distributor’s DataInputQueue. Because we didn’t change anything in the distributor’s default configuration file, the client should send the messages to a queue named distributorDataBus. So let’s make the change:

<span style="color: #606060" id="lnum1">   1:</span> &lt;UnicastBusConfig&gt;

<span style="color: #606060" id="lnum2">   2:</span>   &lt;MessageEndpointMappings&gt;

<span style="color: #606060" id="lnum3">   3:</span>     &lt;add Messages=<span style="color: #006080">&quot;MyMessages&quot;</span> Endpoint=<span style="color: #006080">&quot;distributorDataBus&quot;</span> /&gt;

<span style="color: #606060" id="lnum4">   4:</span>   &lt;/MessageEndpointMappings&gt;

<span style="color: #606060" id="lnum5">   5:</span> &lt;/UnicastBusConfig&gt;

Now you can start the client. Wait for it to initialize and then use enter to send a message. You should see some activity on the distributor. But we’re still missing our workers so the client isn’t getting the replies it is waiting for.

3. Configuring the worker

We must change the worker’s configuration so that it can make itself available to the distributor. And again, the changes are small. First, give the worker a dedicated queue by changing the InputQueue to “worker”. Your MsmqTransportConfig-section should now look like this:

<span style="color: #606060" id="lnum1">   1:</span> &lt;MsmqTransportConfig

<span style="color: #606060" id="lnum2">   2:</span>   InputQueue=<span style="color: #006080">&quot;worker&quot;</span> 

<span style="color: #606060" id="lnum3">   3:</span>   ErrorQueue=<span style="color: #006080">&quot;error&quot;</span>

<span style="color: #606060" id="lnum4">   4:</span>   NumberOfWorkerThreads=<span style="color: #006080">&quot;1&quot;</span>

<span style="color: #606060" id="lnum5">   5:</span>   MaxRetries=<span style="color: #006080">&quot;5&quot;</span>

<span style="color: #606060" id="lnum6">   6:</span> /&gt;

Then, in the UnicastBusConfig-section, type in the DistributorControlAddress and the DistributorDataAddress. You can find the correct values from the distributor’s configuration. Because we’re using the default configuration, the worker’s configuration should end up looking this:

<span style="color: #606060" id="lnum1">   1:</span> &lt;UnicastBusConfig

<span style="color: #606060" id="lnum2">   2:</span>   DistributorControlAddress=<span style="color: #006080">&quot;distributorControlBus&quot;</span>

<span style="color: #606060" id="lnum3">   3:</span>   DistributorDataAddress=<span style="color: #006080">&quot;distributorDataBus&quot;</span>&gt;

<span style="color: #606060" id="lnum4">   4:</span>   &lt;MessageEndpointMappings /&gt;

<span style="color: #606060" id="lnum5">   5:</span> &lt;/UnicastBusConfig&gt;

And that’s it. You can now start the server and after the initialization, the client should receive its reply. Keep pressing enter in the client console and you should see messages flying around.

4. Creating an another workerworker2

We’re almost there. The aim was to have two workers so we’re going to do just that. Here’s how to do this:

  1. Create a copy of the worker’s bin-folder (see picture).
  2. Open the configuration file from the newly copied folder.
  3. Change the InputQueue to “worker2”.
  4. Start the worker.

Now when you again start hitting the enter-key in the client console you should see NServiceBus distributor in action: messages are handled by both of the workers. Here’s a picture from my screen after I had hit the enter for twenty times: capture

Conclusion

Modifying the default FullDuplex sample to use the NServiceBus distributor required only some small changes to the configuration files. In future posts, I’m hoping to expand on the topics related to the NServiceBus configuration: in this post we just skimmed through the changes to get things running.

Links: