Profiles what are they, how do we get there

[johnsimons]

About a week ago I posted a simple question on the discussion list:

Profiles, does anyone uses them?

see original here

And the answers started coming :birthday:

Why did I raise this?

Mostly because I see profiles as just code that gets executed if present. What I mean is that profiles can be replaced with drop-in assemblies, and as we know by default NServiceBus will scan all assemblies and execute the code. So we could just have a LiteProfile.dll that is added to the bin folder in development, eg:

public class LiteProfile : INeedInitialization
{
    public void Init()
    {
        InMemoryPersistence.UseAsDefault();

        Configure.Instance.AsMasterNode();
        Configure.Instance.InMemoryFaultManagement();

        WindowsInstallerRunner.RunInstallers = true;
    }
}

The benefits I see with this approach:

• More discoverable (they just files);
• You can quickly see what "profiles" are being used (look at the file system) vs having to look in windows service properties:
• It also works for self hosting :wink:

  Obviously this solution still has drawbacks

• Order is unpredictable, so very hard to override a profile with another profile.
  This has actually been fixed in v4 so now, if you execute NServiceBus.Host.exe MyProfileA MyProfileB MyProfileC, the profile handlers are executed in order, MyProfileAHandler then MyProfileBHandler and finally MyProfileCHandler
• You don't know what it does unless you look at the code (or name your files with a very long and descriptive name!)

  Annoyances with profiles

If you ever decide to write your own profile, eg:

public class MyProfileA : IProfile
{

}

public class MyProfileAHandler : IHandleProfile<MyProfileA>
{
    public void ProfileActivated()
    {
        Console.Out.WriteLine("MyProfileA");
    }
}

This code will fail with the following exception:

System.Exception was unhandled by user code
  HResult=-2146233088
  Message=Could not find a class which implements 'IConfigureLogging'. If you've specified your own profile, try implementing 'IConfigureLoggingForProfile<T>' for your profile.
  Source=NServiceBus.Core
  StackTrace:
       at NServiceBus.Hosting.Profiles.ProfileManager.GetImplementor[T](Type openGenericType) in c:\Projects\NServiceBus\src\NServiceBus.Core\Hosting\Profiles\ProfileManager.cs:line 90
       at NServiceBus.Hosting.Profiles.ProfileManager.GetLoggingConfigurer() in c:\Projects\NServiceBus\src\NServiceBus.Core\Hosting\Profiles\ProfileManager.cs:line 63
       at NServiceBus.Hosting.GenericHost.PerformConfiguration() in c:\Projects\NServiceBus\src\NServiceBus.Core\Hosting\GenericHost.cs:line 72
       at NServiceBus.Hosting.GenericHost.Start() in c:\Projects\NServiceBus\src\NServiceBus.Core\Hosting\GenericHost.cs:line 27
       at NServiceBus.Hosting.Windows.WindowsHost.Start() in c:\Projects\NServiceBus\src\hosting\NServiceBus.Hosting.Windows\WindowsHost.cs:line 55
       at NServiceBus.Hosting.Windows.Program.<>c__DisplayClassd.<Main>b__5(WindowsHost service) in c:\Projects\NServiceBus\src\hosting\NServiceBus.Hosting.Windows\Program.cs:line 76
       at Topshelf.Internal.ControllerDelegates`1.StartActionObject(Object obj) in c:\Projects\TopShelfForNSB\src\Topshelf\Internal\ControllerDelegates.cs:line 18
       at Topshelf.Internal.IsolatedServiceControllerWrapper`1.<>c__DisplayClass2.<set_StartAction>b__1(TService service) in c:\Projects\TopShelfForNSB\src\Topshelf\Internal\IsolatedServiceControllerWrapper.cs:line 65
       at Topshelf.Internal.ServiceController`1.<.cctor>b__1(ServiceController`1 sc) in c:\Projects\TopShelfForNSB\src\Topshelf\Internal\ServiceController.cs:line 35
       at Magnum.StateMachine.LambdaAction`1.Execute(T instance, Event event, Object parameter) in :line 0
       at Magnum.StateMachine.EventActionList`1.Execute(T stateMachine, Event event, Object parameter) in :line 0
  InnerException: 

Why do I also need to implement IConfigureLoggingForProfile<MyProfileA> ?
It feels strange and unnecessary if I'm happy with the defaults.

[chrisbednarski]

Would there be an easy way to switch between "new drop-in profiles" for different builds (ie. Debug,Release,etc) ?

[johnsimons]

Hi @chrisbednarski, That is a good point, suggestions?

[johnsimons]

@chrisbednarski btw, this is not a "new drop-in profiles", this is just a discussion to find out if we can improve profiles.

[chrisbednarski]

I don't see issues with the way profiles are currently & the way I'm using them.

Crazy idea ... if a separate IConfigureLoggingForProfile<T> is a problem, maybe add ability to use logging from other, existing profiles, ala how the roles work for transports interface IHandleProfileAndLogging<T, L> : IHandleProfile<T>, UsingLoggingFromProfile<L>

Or, maybe not :)

[DavidBoike]

Drop-in style of profiles would make it difficult to do more complex logic like IHandleAnyProfile based on combinations or if/else. I suppose you could just either drop in AssemblyA or Assembly B, but this does make deployment a lot more complex when a lot of people are just doing straight robocopy on the build server's bin/Release directory.

[johnsimons]

But doesn't the same complexity exist with supplying profiles as cmd line args?

On Thursday, August 22, 2013, David Boike wrote:

Drop-in style of profiles would make it difficult to do more complex logic like IHandleAnyProfile based on combinations or if/else. I suppose you could just either drop in AssemblyA or Assembly B, but this does make deployment a lot more complex when a lot of people are just doing straight robocopy on the build server's bin/Release directory.

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/NServiceBus/issues/1463#issuecomment-23044959 .

Regards John Simons NServiceBus

[DavidBoike]

No. I install the endpoint once. Binary swapping makes action required on every deployment.

Your example problem was a from scratch profile. That probably isn't smart to begin with and should be discouraged. In 2.0 I did that because it was nearly impossible to do minor tweaks from a profile that inherited a built in one because things would be double registered. Is that still the case today?

[lcorneliussen]

@ducttapeman NSB now in most cases checks, if a component already has been registered before registering it...

[DavidBoike]

That's what I was thinking. In that case it might be better to do a process where you check to see if key things are configured, and in the exception thrown, don't say "Consider implementing IConfigureLogging" but instead check the inheritance chain for the profile and say "Consider overriding a default profile instead."

[SimonCropp]

moved to https://github.com/Particular/NServiceBus.Host/issues/19