Appsettings.json in a .NET Core Console Application

This is applicable to .NET Core 2.0, and is the equivalent of the old app.config and ConfigurationManager pattern. Below are the steps to set it up.
This is a modified version of Ray Vega’s answer on stackoverflow.

  1. Create a file named appsettings.json at the project root. (The filename can actually be anything, and is referenced below, but appsettings.json is a good convention.)
  2. Add your settings to that file in JSON format. Note that the file is much more flexible than the old app.config, and this is just an option. I currently prefer to have an AppSettings section here:
  3. Set appsettings.json to be copied to the output directory if there have been any changes, since we’ll load it from the default path below (in Visual Studio, right click the file, and choose Properties. Then under the advanced section in the window, set Copy to output directory to Copy if newer):
    Copy if newer settings in Visual Studio
  4. Install these two NuGet packages:

    • Microsoft.Extensions.Configuration.Json
    • Microsoft.Extensions.Options.ConfigurationExtensions
  5. Add an AppSettings.cs file to your project with a class and properties that match the names you added in the JSON file above. For example:

  6. And add the following code to Main in Program.cs, or factored out into a separate function (note the filename “appsettings.json” below — it should match whatever you created above):
  7. You can now access the configuration values using properties of the appSettings property, for example:

'Microsoft.SqlServer.Types' version 10 or higher could not be found

If you have a connection to SQL Server where you’re using spatial types with Entity Framework, and deploying to an Azure service/server, you’re likely to come across the exception:

Spatial types and functions are not available for this provider because the assembly ‘Microsoft.SqlServer.Types’ version 10 or higher could not be found.

While you can install SQL Server, a far easier way around it is to install the NuGet package Microsoft.SqlServer.Types.
After you install that NuGet package, you’ll want to make a call to SqlServerTypes.Utilities.LoadNativeAssemblies prior to any actual calls in Entity Framework.
ASP.NET (e.g. in Global.asax.cs -> Application_Start)

Standalone Application

Additionally, in the current versions of Entity Framework, there is a hardcoded reference to only look for versions 10 and 11 of the Microsoft.SqlServer.Types assembly. You can fix this by doing the following in code (the version number should match the version you’re using via the NuGet package above):

The final version:

Standalone Application:

Allow A New Mime Type Download on WordPress / Azure

After you allow a new MIME type via editing your functions.php file or using a plugin like WP Add Mime Types, you might find that you can’t download the files when running WordPress on Microsoft Azure.
I ran into this problem recently when adding .gpx and .kml files to my site, but you could encounter similar problems with other types. The error message I was getting when attempting to download the files in a browser was:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
The problem is that by default, WordPress runs under Microsoft Windows in Microsoft Azure, but IIS does not serve many types of static content by default. The easiest solution, other than trying to modify the configuration for IIS, itself, is to modify the Web.config file for the web application. In the root of your WordPress application folder, you’ll either see no Web.config file (you can use the first example below as a full file), or you’ll see an existing Web.config file you can modify.
The following piece should allow you to download the files you want (adjust for the types of file extensions and MIME types you’re attempting to allow):

My site already had a Web.config file with a rewrite rule, so I actually modified it to be similar to the below example (the name portion is a placeholder):

BuyDomains Experience

I bought a domain from BuyDomains about two months ago. I was searching for a domain for one of my personal projects using a domain generator (Nameboy), and saw what I thought was a great domain name show up as available. I got out my credit card, and immediately went to my registrar’s site to grab it. Unfortunately, it showed up as already registered. Damn. When I visited the domain in a browser, it turned out it was for sale and brokered (possibly owned?) by BuyDomains. I didn’t realize the domain generators/checkers displayed for-sale domains as well as unregistered ones, but it certainly makes sense now.
Domain name squatting offends me slightly, but it’s mostly because I kick myself for not having bought as many good domains as I could have years ago and squatted them myself. Despite being virtual, a good domain name is an incredibly valuable asset. The domain name BuyDomains was selling seemed like a pretty good deal even though it was obviously priced significantly above a normal registration cost. I’d never dealt with them before, and though I was mildly familiar with them, I was initially leery of the process.
I did some initial research on BuyDomains by doing some searches — I couldn’t find a lot of detailed information (which is why I decided to write this post). The experiences I did find ranged from frustrated people who said BuyDomains had raised the price after initial contact, to people who said BuyDomains was quite willing to negotiate on prices. A lot of people questioned how the domains were priced. How do they assign a value to a domain that is squatted and has never had a legitimate purpose? (The Internet Archive is a good resource to check historical content and see whether a domain was ever used for a legitimate site.) Keyword use and traffic seem to be the only reasonable metrics in assigning value. Keywords are very subjective, though. And when the domain is used in a link farm, this traffic numbers are sure to be skewed. The prices on BuyDomains vary wildly — most I’ve seen are priced between $1,000 and $3,000, but many clear English phrases with .com extensions are at the bottom of the range, while many nonsensical .net and .org names are much higher.
I liked the domain enough, and I’d read enough positive experiences to give the purchase a go, though. The representatives I talked to over email responded quickly and were quite professional. They seemed quite willing to negotiate on the price. I ended up offering approximately 33% less than the initial asking price, and they quickly accepted. I have the feeling they would have gone lower, but I’m not sure how much lower. The checkout process was pretty slick. There were the expected few days lag after payment and before the transfer completed. I got a phone call from another representative just prior to a confirmation email that gave me control of the domain. He was very professional, and though he tried to upsell me on related products, he didn’t push too hard. The registrar the domain was on had a goofy interface (I’m not sure how much of BuyDomains’ business is commission versus domains they own, or if they transfer all their owned domains to this particular registrar). Transferring to my registrar was quite painless, however. I spent much more than an unregistered domain would have cost, but I think the final price was fair, and I’m quite pleased with my experience with BuyDomains.

WCF Proxy Server Authentication

Almost everyone who’s written a .NET application which calls a web service has had to deal with service calls passing through a proxy server. In the past, after generating the service client from WSDL, I’d set up a WebProxy (possibly with NetworkCredential) — which really isn’t all that bad, but somewhat annoying. Now, more ideally, the service calls are via svcutil generated WCF clients. However, handling proxies programmatically in WCF is more difficult since you can’t deal with a nice WebProxy object. You can set credentials via ChannelFactory.Credentials, but this has a drawback — your credentials need to be the same for the proxy and server authentication if they both use the same authentication scheme. The programmatic approach has always struck me as unnatural.
I just discovered a much simpler way to deal with proxies this week. Thankfully, the answer really has nothing to do with WCF. WCF depends on the underlying System.Net subsystem, and by default, .NET clients will not pass their credentials to the default proxy server. This is what had tripped me up in the past. The default errs on the side of security, since you may not want to leak credentials when not necessary. You can instruct System.Net to pass the default credentials via the following config:

If your application is running as a domain user who has access to the proxy server, your WCF, web service, etc. calls will work without further modification. As a matter of practice, I configure my Application Pool identities and Windows Service identities to run under domain user accounts whenever possible.
Sometimes you may need to specify your default proxy if the system cannot autodetect it or you don’t want to use the autodetected proxy. In that case you can do the following (this example also uses default credentials as above):

Using default credentials works in all the situations I’ve encountered, but you may run into the need to specify different credentials in shared hosting environments/etc. To my knowledge, there’s no way to specify particular credentials in .NET configuration files. If you need to specify other credentials for your web proxy and you’re using WCF, you’re stuck specifying them via ChannelFactory.Credentials on your WCF client.