App Config Facility

[a***@public.gmane.org]

Hi,

I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.

I tend to create interfaces for accessing app config settings so that I can
easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.

For example, say I've got some settings like:

<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Email" value="adam-***@public.gmane.org"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>

And a couple of interfaces:

public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}

public interface GitConfig
{
string Email { get; }
string Name { get; }
}

You can configure your container like this:

var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();

container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);

Then just resolve them / inject them as normal.

It also supports getting the settings from Azure, caching, and computed
properties currently.

The code's available on Github
at https://github.com/adamconnelly/WindsorAppConfigFacility.

What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.

Cheers,
Adam

[Ken Egozi]

I have been using the DictionaryAdapterFacility for that purpose for years
now.

Sent from my Windows Phone
------------------------------
From: adam.rpconnelly-***@public.gmane.org
Sent: ‎10/‎9/‎2014 6:11 AM
To: castle-project-devel-/***@public.gmane.org
Subject: App Config Facility

Hi,

I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.

I tend to create interfaces for accessing app config settings so that I can
easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.

For example, say I've got some settings like:

<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Email" value="adam-***@public.gmane.org"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>

And a couple of interfaces:

public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}

public interface GitConfig
{
string Email { get; }
string Name { get; }
}

You can configure your container like this:

var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();

container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);

Then just resolve them / inject them as normal.

It also supports getting the settings from Azure, caching, and computed
properties currently.

The code's available on Github at
https://github.com/adamconnelly/WindsorAppConfigFacility.

What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.

Cheers,
Adam
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to castle-project-devel+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to castle-project-devel-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

[Adam Connelly]

Hi Ken,

I saw an article about that, and it looked pretty cool, but the problem I
had with it is that we host some of our project in azure, and I don't think
you can get access to your config settings in the same way. Instead you
have to make a call to CloudConfigurationManager.GetSetting with the key.

Maybe I just overlooked something obvious at the time though.

Cheers,
Adam

On 9 Oct 2014, at 16:06, Ken Egozi <egozi13-***@public.gmane.org> wrote:

I have been using the DictionaryAdapterFacility for that purpose for years
now.

Sent from my Windows Phone
------------------------------
From: adam.rpconnelly-***@public.gmane.org
Sent: ‎10/‎9/‎2014 6:11 AM
To: castle-project-devel-/***@public.gmane.org
Subject: App Config Facility

Hi,

I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.

I tend to create interfaces for accessing app config settings so that I can
easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.

For example, say I've got some settings like:

<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Email" value="adam-***@public.gmane.org"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>

And a couple of interfaces:

public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}

public interface GitConfig
{
string Email { get; }
string Name { get; }
}

You can configure your container like this:

var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();

container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);

Then just resolve them / inject them as normal.

It also supports getting the settings from Azure, caching, and computed
properties currently.

The code's available on Github at
https://github.com/adamconnelly/WindsorAppConfigFacility.

What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.

Cheers,
Adam
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to castle-project-devel+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to castle-project-devel-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

[hammett]

Looks pretty cool. Good job.

Regarding adding it to windsor, I'd prefer to list it on our website
(maybe with some nuget id reference?) so we give it visibility but
without the implied maintenance obligation.

Post by a***@public.gmane.org
Hi,
I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.
I tend to create interfaces for accessing app config settings so that I can
easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that uses
dynamic proxy to automatically implement a settings interface, so I don't
have to update stuff in two places.
<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>
public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}
public interface GitConfig
{
string Email { get; }
string Name { get; }
}
var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();
container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);
Then just resolve them / inject them as normal.
It also supports getting the settings from Azure, caching, and computed
properties currently.
The code's available on Github at
https://github.com/adamconnelly/WindsorAppConfigFacility.
What I'm wondering is whether you'd be interested in adding this to Windsor,
and if so, what would I need to change for you to accept it. I'm more than
happy to reformat any files to suit your code format, and make any changes
where I've missed stuff.
Cheers,
Adam
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

--
Cheers,
hammett
http://www.d-collab.com/
http://www.hammettblog.com/

[Krzysztof Koźmic]

+1

Post by hammett
Looks pretty cool. Good job.
Regarding adding it to windsor, I'd prefer to list it on our website
(maybe with some nuget id reference?) so we give it visibility but
without the implied maintenance obligation.

Post by a***@public.gmane.org
Hi,
I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.
I tend to create interfaces for accessing app config settings so that I

can

Post by a***@public.gmane.org
easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each

time

Post by a***@public.gmane.org
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that

uses

Post by a***@public.gmane.org
dynamic proxy to automatically implement a settings interface, so I don't
have to update stuff in two places.
<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>
public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}
public interface GitConfig
{
string Email { get; }
string Name { get; }
}
var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();
container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);
Then just resolve them / inject them as normal.
It also supports getting the settings from Azure, caching, and computed
properties currently.
The code's available on Github at
https://github.com/adamconnelly/WindsorAppConfigFacility.
What I'm wondering is whether you'd be interested in adding this to

Windsor,

Post by a***@public.gmane.org
and if so, what would I need to change for you to accept it. I'm more

than

Post by a***@public.gmane.org
happy to reformat any files to suit your code format, and make any

changes

Post by a***@public.gmane.org
where I've missed stuff.
Cheers,
Adam
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
To post to this group, send email to
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

--
Cheers,
hammett
http://www.d-collab.com/
http://www.hammettblog.com/
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

[a***@public.gmane.org]

That's fine by me. In that case I'll look into putting it up on nuget /
symbol source, and add decent documentation to the github page.

Post by a***@public.gmane.org
Hi,
I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.
I tend to create interfaces for accessing app config settings so that I
can easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.
<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>
public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}
public interface GitConfig
{
string Email { get; }
string Name { get; }
}
var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();
container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);
Then just resolve them / inject them as normal.
It also supports getting the settings from Azure, caching, and computed
properties currently.
The code's available on Github at
https://github.com/adamconnelly/WindsorAppConfigFacility.
What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.
Cheers,
Adam

[a***@public.gmane.org]

Hi,

Just to say I've got round to creating a NuGet package, and adding
documentation about how to use the facility to the GitHub page.

All the info about it should be in the readme
at https://github.com/adamconnelly/WindsorAppConfigFacility.

If you fancy adding this to the site, that would be really cool.

Cheers,
Adam

Post by a***@public.gmane.org
That's fine by me. In that case I'll look into putting it up on nuget /
symbol source, and add decent documentation to the github page.

Post by a***@public.gmane.org
Hi,
I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.
I tend to create interfaces for accessing app config settings so that I
can easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.
<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>
public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}
public interface GitConfig
{
string Email { get; }
string Name { get; }
}
var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();
container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);
Then just resolve them / inject them as normal.
It also supports getting the settings from Azure, caching, and computed
properties currently.
The code's available on Github at
https://github.com/adamconnelly/WindsorAppConfigFacility.
What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.
Cheers,
Adam

[Jonathon Rossi]

Our wiki and web site are both editable (with moderation) by users. The
wiki is probably the best place to mention it.

http://docs.castleproject.org/Windsor.MainPage.ashx
https://github.com/castleproject/castleproject.github.io

Post by a***@public.gmane.org
Hi,
Just to say I've got round to creating a NuGet package, and adding
documentation about how to use the facility to the GitHub page.
All the info about it should be in the readme at
https://github.com/adamconnelly/WindsorAppConfigFacility.
If you fancy adding this to the site, that would be really cool.
Cheers,
Adam

Post by a***@public.gmane.org
That's fine by me. In that case I'll look into putting it up on nuget /
symbol source, and add decent documentation to the github page.

Post by a***@public.gmane.org
Hi,
I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.
I tend to create interfaces for accessing app config settings so that I
can easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.
<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>
public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}
public interface GitConfig
{
string Email { get; }
string Name { get; }
}
var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();
container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c => c.WithPrefix("Git."))
);
Then just resolve them / inject them as normal.
It also supports getting the settings from Azure, caching, and computed
properties currently.
The code's available on Github at https://github.com/adamconnelly/
WindsorAppConfigFacility.
What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.
Cheers,
Adam

--

You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

[Adam Connelly]

Cheers - have added it to the wiki now.

Post by Jonathon Rossi
Our wiki and web site are both editable (with moderation) by users. The
wiki is probably the best place to mention it.
http://docs.castleproject.org/Windsor.MainPage.ashx
https://github.com/castleproject/castleproject.github.io

Post by a***@public.gmane.org
Hi,
Just to say I've got round to creating a NuGet package, and adding
documentation about how to use the facility to the GitHub page.
All the info about it should be in the readme at
https://github.com/adamconnelly/WindsorAppConfigFacility.
If you fancy adding this to the site, that would be really cool.
Cheers,
Adam

Post by a***@public.gmane.org
That's fine by me. In that case I'll look into putting it up on nuget /
symbol source, and add decent documentation to the github page.

Post by a***@public.gmane.org
Hi,
I haven't seen anything like this that comes as part of Windsor, but
apologies in advance if I've just ended up reinventing the wheel.
I tend to create interfaces for accessing app config settings so that I
can easily mock them when writing unit tests. What I found myself doing was
ending up having to alter a concrete class with boiler plate code each time
I added a new setting to an application, which was starting to get a bit
annoying. So what I ended up doing was creating a Windsor facility that
uses dynamic proxy to automatically implement a settings interface, so I
don't have to update stuff in two places.
<appSettings>
<add key="Zendesk.Url" value="abc.zendesk.com"/>
<add key="Zendesk.ApiToken" value="aaaaaaaaa"/>
<add key="Git.Name" value="Adam Connelly"/>
</appSettings>
public interface ZendeskConfig
{
string Url { get; }
string ApiToken { get; }
}
public interface GitConfig
{
string Email { get; }
string Name { get; }
}
var container = new WindsorContainer();
container.AddFacility<AppConfigFacility>();
container.Register(
Component.For<IZendeskConfig>().FromAppConfig(c =>
c.WithPrefix("Zendesk.")),
Component.For<IGitConfig>().FromAppConfig(c =>
c.WithPrefix("Git."))
);
Then just resolve them / inject them as normal.
It also supports getting the settings from Azure, caching, and computed
properties currently.
The code's available on Github at https://github.com/adamconnelly/
WindsorAppConfigFacility.
What I'm wondering is whether you'd be interested in adding this to
Windsor, and if so, what would I need to change for you to accept it. I'm
more than happy to reformat any files to suit your code format, and make
any changes where I've missed stuff.
Cheers,
Adam

--

You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an
To post to this group, send email to
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.

--
Jono
--
You received this message because you are subscribed to a topic in the
Google Groups "Castle Project Development List" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/castle-project-devel/5l4bNqUVmls/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
.
Visit this group at http://groups.google.com/group/castle-project-devel.
For more options, visit https://groups.google.com/d/optout.