How to get settings in middleware? - configuration

I'm sure this has got to be a duplicate, but I've been searching way too long and still can't find the answer.
I want to access configuration options (from a json file, although I don't think the source matters in regard to my question) from here:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.Run(async context =>
{
// Get my config values here and do something with them
await Task.CompletedTask;
});
}
I could use var x = Config.GetValue<string>("AppSettings:MySetting:0"); but because it's a list I would have to create a loop and retrieve values until I get a null value and all that so I would rather do the IOptions thing so it loads it in a strongly typed class for me. I have this code in ConfigureServices:
services.AddOptions();
services.Configure<AppSettings>(Config.GetSection("AppSettings"));
but I just don't know how to get at the object that's registered there from within the Configure method.
I also tried inspecting the value of Config.GetSection("AppSettings") while debugging and found that under the json provider I could see my settings. However, while that's available in the inspector, I can't see how I can directly access my list. That is, I can access my list one value at a time using GetValue() but I can't just access the whole list as one value.

As often seems to happen, I finally figured out what I was looking for right after making a post here. Basically, I don't need IOptions or anything else having to do with DI for my scenario. I just needed to use .Bind() to bind the settings to an instance of my class:
AppSettings a = new AppSettings();
Config.GetSection("AppSettings").Bind(a);

Related

Can you preview ASP.NET Core's appsettings.json environment overrides?

In ASP.NET Core, the JsonConfigurationProvider will load configuration from appsettings.json, and then will read in the environment version, appsettings.{Environment}.json, based on what IHostingEnvironment.EnvironmentName is. The environment version can override the values of the base appsettings.json.
Is there any reasonable way to preview what the resulting overridden configuration looks like?
Obviously, you could write unit tests that explicitly test that elements are overridden to your expectations, but that would be a very laborious workaround with upkeep for every time you change a setting. It's not a good solution if you just wanted to validate that you didn't misplace a bracket or misspell an element name.
Back in ASP.NET's web.config transforms, you could simply right-click on a transform in Visual Studio and choose "Preview Transform". There are also many other ways to preview an XSLT transform outside of Visual Studio. Even for web.config parameterization with Parameters.xml, you could at least execute Web Deploy and review the resulting web.config to make sure it came out right.
There does not seem to be any built-in way to preview appsettings.{Environment}.json's effects on the base file in Visual Studio. I haven't been able to find anything outside of VS to help with this either. JSON overriding doesn't appear to be all that commonplace, even though it is now an integral part of ASP.NET Core.
I've figured out you can achieve a preview with Json.NET's Merge function after loading the appsettings files into JObjects.
Here's a simple console app demonstrating this. Provide it the path to where your appsettings files are and it will emit previews of how they'll look in each environment.
static void Main(string[] args)
{
string targetPath = #"C:\path\to\my\app";
// Parse appsettings.json
var baseConfig = ParseAppSettings($#"{targetPath}\appsettings.json");
// Find all appsettings.{env}.json's
var regex = new Regex(#"appsettings\..+\.json");
var environmentConfigs = Directory.GetFiles(targetPath, "*.json")
.Where(path => regex.IsMatch(path));
foreach (var env in environmentConfigs)
{
// Parse appsettings.{env}.json
var transform = ParseAppSettings(env);
// Clone baseConfig since Merge is a void operation
var result = (JObject)baseConfig.DeepClone();
// Merge the two, making sure to overwrite arrays
result.Merge(transform, new JsonMergeSettings
{
MergeArrayHandling = MergeArrayHandling.Replace
});
// Write the preview to file
string dest = $#"{targetPath}\preview-{Path.GetFileName(env)}";
File.WriteAllText(dest, result.ToString());
}
}
private static JObject ParseAppSettings(string path)
=> JObject.Load(new JsonTextReader(new StreamReader(path)));
While this is no guarantee there won't be some other config source won't override these once deployed, this will at least let you validate that the interactions between these two files will be handled correctly.
There's not really a way to do that, but I think a bit about how this actually works would help you understand why.
With config transforms, there was literal file modification, so it's easy enough to "preview" that, showing the resulting file. The config system in ASP.NET Core is completely different.
It's basically just a dictionary. During startup, each registered configuration provider is run in the order it was registered. The provider reads its configuration source, whether that be a JSON file, system environment variables, command line arguments, etc. and builds key-value pairs, which are then added to the main configuration "dictionary". An "override", such as appsettings.{environment}.json, is really just another JSON provider registered after the appsettings.json provider, which obviously uses a different source (JSON file). Since it's registered after, when an existing key is encountered, its value is overwritten, as is typical for anything being added to a dictionary.
In other words, the "preview" would be completed configuration object (dictionary), which is composed of a number of different sources, not just these JSON files, and things like environment variables or command line arguments will override even the environment-specific JSON (since they're registered after that), so you still wouldn't technically know the the environment-specific JSON applied or not, because the value could be coming from another source that overrode that.
You can use the GetDebugView extension method on the IConfigurationRoot with something like
app.UseEndpoints(endpoints =>
{
if(env.IsDevelopment())
{
endpoints.MapGet("/config", ctx =>
{
var config = (Configuration as IConfigurationRoot).GetDebugView();
return ctx.Response.WriteAsync(config);
});
}
});
However, doing this can impose security risks, as it'll expose all your configuration like connection strings so you should enable this only in development.
You can refer to this article by Andrew Lock to understand how it works: https://andrewlock.net/debugging-configuration-values-in-aspnetcore/

Windsor WcfFacility: Setting ServiceBehavior properties

I'm hosting a service using Windsor's WCF Facility, but I can't get UseSynchronisationContext and ConcurrencyMode set that one would normally do using the ServiceBehaviorAttribute. I've seen two options that apparently should work (but tried both to no avail):
Registering ServiceBehaviorAttribute as a Component for IServiceBehavior
Modifying the Description collection of Behaviors in the OnCreated configuration callback in the WCF registration.
A third method that I've tried is using AddExtensions, but that results in an exception because there's already a ServiceBehaviorAttribute (by default?) in the list of Behaviors. This is also the case with method 2, but in that case I can remove it and add a new one, or modify the existing entry.
It's really frustrating that there doesn't seem any documentation on this except a line stating 'Remove the ServiceBehaviorAttribute' from your services, apparently because it can conflict with the WcfFacility.
Can someone point me on how to properly do this? Any hint is appreciated!
Unfortunately I didn't properly test. Modifying the properties of the ServiceBehaviorAttribute in the list of Behaviors of the Description property in the OnCreated action actually works as intended.
Sample registration:
container.Register(Component.For<IWCFWarehouseServiceAsyncCallback>()
.ImplementedBy<WarehouseService>()
.AsWcfService(new DefaultServiceModel()
.AddBaseAddresses(baseAddress)
.OnCreated(host =>
{
var sb = host.Description.Behaviors.Find<ServiceBehaviorAttribute>();
sb.UseSynchronizationContext = false;
sb.ConcurrencyMode = ConcurrencyMode.Reentrant;
})
.AddEndpoints(WcfEndpoint.BoundTo(binding).At("WarehouseService"))));

Web API seems to be caching JsonFormatter with OData requests?

TL;DR: My OData requests seem to be hitting my custom JsonFormatter once and only once per OData GET method (per controller), which results in "stuck" (cached?) custom formatting.
I am working on a Web API project, and have implemented and registered my own JsonMediaTypeFormatter:
config.Formatters.Clear();
config.Formatters.Add(MyJsonFormatter);
'MyJsonFormatter' has custom implementations of the following:
`-> SerializerSettings
`-> ContractResolver
`-> CreateProperty
In my protected override CreateProperty(MemberInfo member, MemberSerialization memberSerialization) method, I restrict certain properties from being serialized based on user permissions.
This works great for all my API endpoints except for my OData enabled GET requests. Each controller has a GET method using the Primary Keys of the object, and an OData GET method which has a format similar to the following:
[HttpGet, Route]
public PageResult<Customer> GetOData(ODataQueryOptions<Customer> options)
{
IQueryable qCustomer = options.ApplyTo(_args.Context.Customers);
return new PageResult<Customer>(qCustomer as IEnumerable<Customer>, Request.GetNextPageLink(), Request.GetInlineCount());
}
If I put a breakpoint on my overwritten CreateProperty method, it gets hit with every API request. However, it will only get hit once per OData GET method per controller. So a subsequent call from a different user with different permissions skips my code and gives me the formatting used in the first call.
If I restart the API, I can again hit the breakpoint (once), and get my formatting permissions for the user the call was made by, but subsequent calls (no matter the user) do not hit my breakpoint. Obviously, restarting the API for every OData request is not a solution I can live with.
I have put almost a full day into researching this, and have found several posts (here, here, here, etc.) which lead me to believe I need to implement my own ODataMediaTypeFormatter.
However, if this is the case, why is it hitting my JsonFormatter breakpoint? It seems like it uses my formatter, somehow caches my format permissions for that controller, and uses them from then on.
(Secondly, creating my own ODataFormatter does not seem to be a valid option anymore, since the codebase has apparently changed since this post - CreateEdmTypeSerializer does not exist. (I'm using Microsoft ASP.NET Web API 2.1 OData, version 5.1.2).)
Question: Is there a way I can get OData to play nicely with my JsonFormatter, and run through my custom CreateProperty code for each request?
If someone can at minimum explain what is going on here, it may help to point me in the direction I need to go, but right now my brain is just melting. :P
Update: I published to IIS and found that if I recycle the app pool, the formatting seems to be refreshed. So it definitely seems that something is being cached, the question is 'what' and 'why' - do PageResults automatically get cached? How do I stop whatever is being cached from being cached?
I don't know that my question was asked very well, as at the time I didn't entirely know what I was looking for or what was going wrong... However, since then, I have found an answer and figured I would post in just in case someone else runs into my issue.
The issue I was having is that I need to not serialize specific properties in my webapi Json response based on the permissions of the caller. The problem was, the first call upon running the API worked fine, however subsequent calls were not hitting my breakpoints, and were being returned with the permissions of the first request.
The resolution I found was to override another method in my ContractResolver to disable caching for the types I didn't want cached (in this case, anything with Entity as its base class).
public class SecurityContractResolver : DefaultContractResolver
{
public override JsonContract ResolveContract(Type type)
{
if (type == null)
throw new ArgumentNullException("type");
if (type.IsSubclassOf(typeof(Entity)))
return CreateContract(type); //don't use cache in base method - we need different contract resolution per user / permissions
return base.ResolveContract(type); // <-- the base class calls CreateContract and then caches the contract
}
.....
}
Seems to be working great so far. Hope this helps someone!

Use MessageDialog/MessageBox with Portable Class Library and MVVM Light

I´m developing an App that will be available for Windows Phone 8 and the Windows Store. To reduce redundancy I´m using a Portable Class Library (PCL) and on top of that I'm trying to apply the MVVM pattern with the help of the MVVM Light PCL Toolkit. The ViewModels are placed in the PCL and are bound directly in the XAML of the Apps pages.
When the data is received without an error, everything works fine. But I don´t know how to get the exceptions/error message back to the App when errors do happen.
Inside the Windows Store App errors will show as a MessageDialog while the Wp8 App will use the MessageBox class. Obviously the PCL isn´t aware of any of these classes. What I´m not getting is how to know if a ViewModel ran into an error, and how to get the message inside the App. Is this even possible when the ViewModels are bound inside the XAML?
The code in the ViewModel (inside the PCL) looks like this:
DataService.Authenticate((token, error) =>
{
if (error != null)
{
// This is, obviously, not going to work.
MessageBox.Show(error.Message);
return;
}
Token = token;
});
So I have to save the error somehow and let the App itself know the error has occurred, and then call the matching way of showing the error to the user.
Currently I´m thinking of something like defining an Error-property inside the BaseViewModel and fill it when errors in the ViewModel occur. Then, in the CodeBehind of the pages, make them aware of the current ViewModel and bind a PropertyChanged-event to this Error-property. But I was not able to implement it yet, so I don't know if this is even the right way to go.
Do I have to step down from the idea to bind the ViewModels inside the XAML, and do I instead have to initialize them inside the pages Codebehind?
Your instinct is correct, but there are more than a few ways of going about this.
First and foremost, you can use Mvvm's Messaging library, which will allow your ViewModel to send messages directly to your View. Your View can then handle it in any way it wishes, including but not limited to using a MessageDialog.
Secondly, you can also create a Function or Action (likely the former) in your ViewModelLocator for ShowMessageDialog. This Function will likely take a string and return a Task. Then, after you initialize your ViewModelLocator initially, you can inject your ShowMessageDialog code. Your ViewModels can then use whatever platform's MessageDialogs that they please.
Ex:
Note: This code uses the BCL Async libraries that are accessible in Nuget. They work in the PCL just fine.
ViewModelLocator:
public static Func<string, Task> ShowMessageDialog { get; set; }
App.xaml.cs:
ViewModelLocator.ShowMessageDialog = (message) =>
{
// For Windows Phone
return TaskFactory.StartNew(() => MessageBox.Show(message));
// For Windows 8
MessageDialog md = new MessageDialog(message);
return md.ShowAsync().AsTask();
};
ViewModel:
await ViewModelLocator.ShowMessageDialog("This is my message.");
Secondary Note: The md.ShowAsync().AsTask(); must be run on the UI Thread. This means that you will have to invoke it via the dispatcher in the case that you are running it in a task asynchronously. This is possible using a similar method of injecting the use of the app's CoreDispatcher via the RunAsync method.
This means that you can, on any platform (Windows 8 and Windows Phone shown above), inject whatever Message Dialog system you want and use it in your PCL.
I would say that it is much easier to do the first method I suggested, as that is what it is there for, but the Function method version is definitely helpful at times.

Return read-only ui component in Flex

In Flex, I want to create some variable that would hold a dictionary of ui components used throughout my application. Ideally, there would be a function in Application component that would return component for id:
public function getComponent4Id(id:String):UIComponent {}
Then I would access component using the following line:
var myComponent:UIComponent = FlexGlobals.topLevelApplication.getComponent4Id("someId");
Now, the only problem is: I want the component returned to be read-only.
It is very convenient to read some properties of myComponent from every corner of application, but I don't want my developers to abuse it and change myComponent.
Is it possible to return a copy of myComponent? Or is it possible to make it read-only somehow?
In the situation you describe, it is not possible to retrieve read only components.
You can create read only variables by implementing get methods without set methods. Something like this:
public var get myValue():UIComponent{
return UIComponent;
}
This would allow you to retrieve the UIComponent instance, myValue, from the component; but you would not be able to set it.
However, this would not prevent people from changing properties on the returned UIComponent unless those properties were also implemented as read only.
I'll add that there is already a method, getChildByName() to retrieve a child component by name. If you have an instance to a parent, you can use this to access the children.
All that said, I'm not sure I completely understand what you hope to achieve; with this functionality.