Merhaba, siteme hoşgeldiniz.

Paylaşımları kaçırmamak için bültene kayıt olmayı unutmayın.

Çarşamba, 08 Mart 2017 / Published in Uncategorized

Previous posts:

Visual Studio 2017, .NET Core SDK 1.0, F# 4.1

Yesterday, we had a big product launch! Visual Studio 2017 is here, and with it come the releases of .NET Core SDK 1.0, and F# 4.1. Check out the posts for all the details:

Get the bits now:

On .NET

In last week’s episode, Phillip Carter gave a tour of F#. This episode is two full hours of delicious F# aimed mainly at C# developers with no prior F# experience:

This week, we’ll have two shows. First, Scott Hunter will give a recap of yesterday’s announcements and what they mean for .NET. Second, we’ll have Matt Watson from Stackify to talk about Prefix, a lightweight dev tool for the Web that shows real-time logs, errors, queries, and more. We’ll stream live on Channel 9 at 9:30AM Pacific Time on Wednesday, then 10AM on Thursday. We’ll take questions on Gitter’s dotnet/home channel and on Twitter. Please use the #onnet tag. It’s OK to start sending us questions in advance if you can’t do it live during the shows.

Happy Birthday .NET!

We have another Happy Birthday .NET video for you this week. John Shewchuk is a Technical Fellow in charge of developer experience. He worked on Visual InterDev, drove the first release of Visual Studio, and was part of the architectural team for the very first and subsequent releases of .NET.

Tool of the week: FNA

FNA is a reimplementation of the Microsoft XNA libraries. The main contributor to the project, Ethan Lee, has ported two dozen XNA games already, including FEZ, Bastion, and Terraria.

Game of the week: Pyre

Pyre is a role-playing game in which you lead a band of exiles to freedom. To do this, you must fight through ancient competitions that are spread across a mystical purgatory. Each battle will bring you and your party closer to their freedom as they gain access to new abilities. Pyre will feature both a campaign and a two-player versus mode, letting you challenge a friend to one of fast-paced ritual showdowns.

Pyre is being created by Supergiant Games using C# and their own custom engine. It is under development but will be launching on Steam and PlayStation 4.

User group meeting of the week: Linux and microservice architecture in NC

Tonight Wednesday, March 8, at 5:30PM in Morrisville, NC, the TRINUG.NET group holds a meeting on .NET, Linux, and microservice architecture.

.NET

ASP.NET

C#

F#

New F# Language Suggestions:

Check out F# Weekly for more great content from the F# community.

Xamarin

UWP

Azure

Data

Games

And this is it for this week!

Contribute to the week in .NET

As always, this weekly post couldn’t exist without community contributions, and I’d like to thank all those who sent links and tips. The F# section is provided by Phillip Carter, the gaming section by Stacey Haffner, and the Xamarin section by Dan Rigby, and the UWP section by Michael Crump.

You can participate too. Did you write a great blog post, or just read one? Do you want everyone to know about an amazing new contribution or a useful library? Did you make or play a great game built on .NET? We’d love to hear from you, and feature your contributions on future posts:

This week’s post (and future posts) also contains news I first read on The ASP.NET Community Standup, on Weekly Xamarin, on F# weekly, and on Chris Alcock’s The Morning Brew.

Çarşamba, 08 Mart 2017 / Published in Uncategorized

Back in June, when ASP.NET Core was still in RC2, I wrote a post about reloading strongly typed Options when the underlying configuration sources (e.g. a JSON) file changes. As I noted in that post, this functionality was removed prior to the release of ASP.NET Core 1.0.0, as the experience was a little confusing. With ASP.NET Core 1.1.0, it's back, and much simpler to use.

In this post, I'll show how you can use the new IOptionsSnapshot<> interface to simplify reloading strongly typed options. I'll provide a very brief summary of using strongly typed configuration in ASP.NET Core, and touch on the approach that used to be required with RC2 to show how much simpler it is now!

tl;dr; To have your options reload when the underlying file / IConfigurationRoot changes, just replace any usages of IOptions<> with IOptionsSnapshot<>

The ASP.NET Core configuration system

The configuration system in ASP.NET Core is rather different to the approach taken in ASP.NET 4.X. Previously, you would typically store your configuration in the AppSettings section of the XML web.config file, and you would load these settings using a static helper class. Any changes to web.config would cause the app pool to recycle, so changing settings on the fly this way wasn't really feasible.

In ASP.NET Core, configuration of app settings is a more dynamic affair. App settings are still essentially key-value pairs, but they can be obtained from a wide array of sources. You can still load settings from XML files, but also JSON files, from the command line, from environment variables, and many others. Writing your own custom configuration provider is also possible if you have another source you wish to use to configure your application.

Configuration is typically performed in the constructor of Startup, loading from multiple sources:

public Startup(IHostingEnvironment env)  
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

public IConfigurationRoot Configuration { get; }  

This constructor creates a configuration object, loading the configuration found in each of the file sources (two JSON files and Environment Variables in this case). Each source supplies a set of key-value pairs, and each subsequent source overwrites values found in earlier sources. The final IConfigurationRoot is essentially a dictionary of all the final key-value pairs from all of your configuration sources.

It is perfectly possible to use this IConfigurationRoot directly in your application, but the suggested approach is to use strongly typed settings instead. Rather than injecting the whole dictionary of settings whenever you need to access a single value, you take a dependency on a strongly typed POCO C# class. This can be bound to your configuration values and used directly.

For example, imagine I have the following values in appsettings.json:

{
  "MyValues": {
    "DefaultValue" : "first"
  }
}

This could be bound to the following class:

public class MyValues  
{
    public string DefaultValue { get; set; }
}

The binding is setup when you are configuring your application for dependency injection in the ConfigureServices method:

public void ConfigureServices(IServiceCollection services)  
{
    services.Configure<MyValues>(Configuration.GetSection("MyValues"));
}

With this approach, you can inject an instance of IOptions<MyValues> into your controllers and access the settings values using the strongly typed object. For example, a simple web API controller that just displays the setting value:

[Route("api/[controller]")]
public class ValuesController : Controller  
{
    private readonly MyValues _myValues;
    public ValuesController(IOptions<MyValues> values)
    {
        _myValues = values.Value;
    }

    // GET api/values
    [HttpGet]
    public string Get()
    {
        return _myValues.DefaultValue;
    }
}

would give the following output when the url /api/Values is hit:

Reloading strongly typed options in ASP.NET Core RC2

Now that you know how to read settings in ASP.NET Core, we get to the interesting bit – reloading options. You may have noticed that there is a reloadOnChange parameter on the AddJsonFile method when building your configuration object in Startup. Based on this parameter it would seem like any changes to the underlying file should propagate into your project.

Unfortunately, as I explored in a previous post, you can't just expect that functionality to happen magically. While it is possible to achieve, it takes a bit of work.

The problem lies in the fact that although the IConfigurationRoot is automatically updated whenever the underlying appsettings.json file changes, the strongly typed configuration IOptions<> is not. Instead, the IOptions<> is created as a singleton when first requested and is never updated again.

To get around this, RC2 provided the IOptionsMonitor<> interface. In principle, this could be used almost identically to the IOptions<> interface, but it would be updated when the underlying IConfigurationRoot changed. So, for example, you should be able to modify your constructor to take an instance of IOptionsMonitor<MyValues> instead, and to use the CurrentValue property:

public class ValuesController : Controller  
{
    private readonly MyValues _myValues;
    public ValuesController(IOptionsMonitor<MyValues> values)
    {
        _myValues = values.CurrentValue;
    }
}

Unfortunately, as written, this does not have quite the desired effect – there is an additional step required. As well as injecting an instance of IOptionsMonitor you must also configure an event handler for when the underlying configuration changes. This doesn't have to actually do anything, it just has to be set. So for example, you could set the monitor to just create a log whenever the underlying file changes:

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory, IOptionsMonitor<MyValues> monitor)  
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();

    monitor.OnChange(
        vals =>
        {
            loggerFactory
                .CreateLogger<IOptionsMonitor<MyValues>>()
                .LogDebug($"Config changed: {string.Join(", ", vals)}");
        });

    app.UseMvc();
}

With this in place, changes to the underlying appsettings.json file will be reflected each time you request an instance of IOptionsMonitor<MyValues> from the dependency injection container.

The new way in ASP.NET Core 1.1.0

The approach required for RC2 felt a bit convoluted and was very easy to miss. Microsoft clearly thought the same, as they removed IOptionsMonitor<> from the public package when they went RTM with 1.0.0. Luckily, a new improved approach is back with version 1.1.0 of ASP.NET Core.

No additional setup is required to have your strongly typed options reload when the IConfigurationRoot changes. All you need to do is inject IOptionsSnapshot<> instead of IOptions<>:

public class ValuesController : Controller  
{
    private readonly MyValues _myValues;
    public ValuesController(IOptionsSnapshot<MyValues> values)
    {
        _myValues = values.Value;
    }
}

No additional faffing in the ConfigureMethod, no need to setup additional services to make use of IOptionsSnapshot – it is all setup and works out of the box once you configure your strongly typed class using

public void ConfigureServices(IServiceCollection services)  
{
    services.Configure<MyValues>(Configuration.GetSection("MyValues"));
}

Trying it out

To make sure it really did work as expected, I created a simple project using the values described in this post, and injected both an IOptions<MyValues> object and an IOptionsSnapshot<MyValues> object into a web API controller:

[Route("api/[controller]")]
public class ValuesController : Controller  
{
    private readonly MyValues _myValues;
    private readonly MyValues _snapshot;
    public ValuesController(IOptions<MyValues> optionsValue, IOptionsSnapshot<MyValues> snapshotValue)
    {
        _myValues = optionsValue.Value;
        _snapshot = snapshotValue.Value;
    }

    // GET api/values
    [HttpGet]
    public string Get()
    {
        return $@"
IOptions<>:         {_myValues.DefaultValue}  
IOptionsSnapshot<>: {_snapshot.DefaultValue},  
Are same:           {_myValues == _snapshot}";  
    }
}

When you hit /api/Values this simply writes out the values stored in the current IOptions and IOptionsSnapshot<> values as plaintext:

With the application still running, I edited the appsettings.json file:

{
  "MyValues": {
    "DefaultValue" : "The second value"
  }
}

I then reloaded the web page (without restarting the app), and voila, the value contained in IOptionsSnapshot<> has updated while the IOptions value remains the same:

One point of note here – although the initial values are the same for both IOptions<> and IOptionsSnapshot<>, they are not actually the same object. If I had injected two IOptions<> objects, they would have been the same object, but that is not the case when one is an IOptionsSnapshot<>. (This makes sense if you think about it – you couldn't have them both be the same object and have one change while the other stayed the same).

If you don't like to use IOptions

Some people don't like polluting their controllers by using the IOptions<> interface everywhere they want to inject settings. There are a number of ways around this, such as those described by Khalid here and Filip from StrathWeb here. You can easily extend those techniques to use the IOptionsSnapshot<> approach, so that all of your strongly typed options classes are reloaded when an underlying file changes.

A simple solution is to just delegate the request for the MyValues object to the IOptionsSnapshot<MyValues>.Value value, by setting up a delegate in ConfigureServices:

public void ConfigureServices(IServiceCollection services)  
{
    services.Configure<MyValues>(Configuration.GetSection("MyValues"));
    services.AddScoped(cfg => cfg.GetService<IOptionsSnapshot<MyValues>>().Value);
}

With this approach, you can have reloading of the MyValues object in the ValuesController, without needing to explicitly specify the IOptionsSnapshot<> interface – just use MyValues directly:

public class ValuesController : Controller  
{
    private readonly MyValues _myValues;
    public ValuesController(MyValues values)
    {
        _myValues = values;
    }
}

Summary

Reloading strongly typed options in ASP.NET Core when the underlying configuration file changes is easy when you are using ASP.NET Core 1.1.0. Simply replace your usages of IOptions<> with IOptionsSnapshot<>.

Çarşamba, 08 Mart 2017 / Published in Uncategorized

.NET Core application, where is my EXE, how to publish

Short answer, there isn’t one.  When you compile your .NET Core console application for example, you get a DLL.  Then you execute it using the DOTNET command from the .NET Core SDK found here.

I wrote 2 articles about a .NET Core console application here and here which resulted in the creation of a DLL called: helloworldsleepy-webjob.dll

I right-clicked my .NET Core console application and select the Publish… menu item, which opened a wizard, similar to that shown in Figure 1.

Figure 1, how to publish a .NET Core application

Select the location where you want the PublishOutput to be placed and click the Publish button, see Figure 2.

Figure 2, how to publish a .NET Core application, no EXE?

For testing, I then copied the contents of that directory into C:\Temp\helloworldsleepy-webjob and ran DOTNET helloworldsleepy-webjob.dll as shown in Figure 3.

Figure 3, how to execute a .NET Core console application

It runs as expected.

Çarşamba, 08 Mart 2017 / Published in Uncategorized

Most organizations today consume open source software in their development projects. The reuse of components enables great productivity gains. However, this practice has an unintended consequence: you can reuse security vulnerabilities or violate licenses without realizing the risk. I wrote about this in an article in MSDN Magazine on Rugged DevOps.

For users of VSTS, there is now a great extension to help discover and remediate the risk: WhiteSource Bolt is now available in the marketplace. WhiteSource, an open source security & management platform provider, has been working with Microsoft  to offer an integrated solution within the VSTS product, so that you can scan components directly from your build and release pipeline. TFS support is coming soon.

When you install the Bolt extension, it is ready to use in trial mode. I found that I could add the build task with no parameter configuration and run the component scan successfully on first try. It’s an extraordinarily easy flow.

You add Bolt as a build task, save and queue the build and then you have a report on vulnerabilities and licenses that looks something like this:

There are a few things to note about this report. In the table under the summary, you see each vulnerable component listed. On the left is a hyperlink to the source information about the vulnerability. On the right, for each component, is a link to the most recommended fix.

If you’re a security geek, you’ll probably note that of these seven high-vulnerability components, only one is enumerated in the National Vulnerability Database (as CVE-2016-2515). WhiteSource identifies the other six from its own security research.

If you have Visual Studio Enterprise , you now get 6 months use of WhiteSource Bolt for one team project included with your subscription. You can redeem a code from your benefits page. WhiteSource has posted a page for VS subscribers with more detailed instructions..

 

TOP