Notes from the ASP.NET Community Standup – April 5, 2016

April 6, 2016, 8:14 am

≫ Next: WhereYouAt Demo from Build 2016: Demo Flow and UI

≪ Previous: Build 2016 Wrap up

This is the next in a series of blog posts that will cover the topics discussed in the ASP.NET Community Standup. The community standup is a short video-based discussion with some of the leaders of the ASP.NET development teams covering the accomplishments of the team on the new ASP.NET Core framework over the previous week. Within 30 minutes, Scott Hanselman, Damian Edwards, Jon Galloway and an occasional guest or two discuss new features and ask for feedback on important decisions being made by the ASP.NET development teams.

Each week the standup is hosted live on Google Hangouts and the team publishes the recorded video of their discussion to YouTube for later reference. The guys answer your questions LIVE and unfiltered. This is your chance to ask about the why and what of ASP.NET! Join them each Tuesday on live.asp.net where the meeting’s schedule is posted and hosted.

This week’s meeting is below:

We broke the Build! Actually, Build broke Hanselman and team as they are wiped from a great week at the conference.

Community Links:

Build 2016 Wrap Up on the MSDN WebDev blog – a wrapup article from your wonderful transcriptionist complete with the ASP.NET team’s videos and links to the workshop code from the event. If you didn’t get a chance to see a session you wanted or get into the workshop, GO TO THIS POST because it has all of the ASP.NET goodies from the event. Seriously, stop reading, go now… we’ll save this post for later so you can read it. When you’re done reading it, give it a 5 star rating because Scott asked you to.

Oh.. And I’ve added Jon’s Q+A with the Channel 9 team to this post as well.

An answer to a previous question on the standup that we took to blog form for a complete answer: Dependency Injection in ASP.NET Core Is on the MSDN blog as well.

ASP.NET Monsters this week are covering Donut Hole Caching. The team likes to call this technique ‘Fragment Caching’, but Jon pointed out that its nowhere near as appetizing as donut holes.

Jon shared the link to the code labs from Build. If you didn’t find them in the blog post above, they’re here. The labs should take about 2-3 hours each for four hours.

Rick Anderson and friends completed some documentation on the docs.asp.net site about localization.

Cecil Phillip shared a GitHub repository where he showed how he migrated a WebAPI 2 application to ASP.NET Core.

Marius Schulz published a post about inline routing constraints.

Mike Brind gives us another good post this week, this time about a tool from Stackify called Prefix for application performance monitoring.

Richard Kiene shared some content about running ASP.NET Core on Joyent Triton.

Marcin Zablocki published a post about using Redis HTML cache with ASP.NET Core.

Nicolas Bello Camilletti has two posts about Angular 2 and ASP.NET Core: Routing in Angular 2 and using with the ASP.NET Core APIs.

The Microsoft Edge team had a one day conference on Monday the 4th of April and published a great site about sharing their platform data.

Fanie Reynders has a video and post about how MVC and ASP.NET Core work together. Scott complemented the format of this post for sharing slides, a video recording of the presentation, code, and a text write-up.

Question of the week:

Previously, we used to be able to configure “ASP.NET 5″ builds on Visual Studio team services with this technique. Can we ensure that technique, or something like it, will continue to be supported?

— Yes.. Visual Studio Team Services support is expected to be delivered with RTM.

Accomplishments

Damian is back from a week of vacation and updated us on the current state of the framework development. The ASP.NET team is currently entered “Ask Mode” which is one of the steps in the release process that Microsoft engineering uses. Damian gave us a quick walk-through of those steps:

Open check-ins and bug fixes
Tell Mode – engineers are free to check in bug fixes and are expected to tell a central authority about every check in
Ask Mode – the burden of higher quality fixes is raised, something Microsoft calls the ‘bug bar’ is raised. This is a period of development where new feature development stops and a central authority holds meetings to review changes and bug fixes before release. The engineering team must ask for permission to submit any changes to the code that is being reviewed prior to release.
Escrow – Named after the older process where the gold disk was written that contained the version that would be shipped to manufacturing and was placed in escrow while final testing was done.

The Core framework is currently in escrow and they are tracking issues to work through the end of their escrow phase. They have not announced a date for their release, but are quite stable right now. The ASP.NET team right now requires all changes to be approved and verified by Damian and Eilon, the development manager. The team is still early in ask mode and are not ready to declare when it will conclude. This is a good milestone to have reached.

Damian indicated that the .NET CLI and installers are in a good state, which is helpful for the ASP.NET framework that now depends on them. With them completed, the ASP.NET team has a stable foundation to focus on. During the Build conference, there was some rumbling about targeting April for RC2 and the team is hoping to hit that. Damian isn’t quite ready to set a date yet, but is hopeful that it will be in April. There are a lot of new concepts in the .NET Core and CLI release, and Damian encourages everyone to check out Scott Hanselman and Scott Hunter’s session at Build on the Future of .NET.

Questions

Question: What can we expect in terms of difficulty of migrating from RC1 to RC2?

There is a document in the works, but not published yet. Among the changes you’ll need to know are minor project structure changes, the Visual Studio tooling will support both versions, a number of APIs had breaking changes. In RC2, the ASP.NET Core application startup process has changed and you will need to configure your project to use this new model. There are tweaks at every layer and you will be impacted.

Question: Will RC2 be fully CLI functional or will it require some DNX configuration?

It will be all CLI, there will be no DNX any longer

Question: For RC1, dnu publish required a manual triggering of gulp tasks. Will this be streamlined in RC2?

In RC1 you could use the scripts section in project.json you could define several tasks to run pre-publish, post-publish, etc. Damian shared the project.json from the live.asp.net site and showed the scripts/pre-publish section and indicated that this feature will continue to be supported in RC2. I have included that section of Damian’s source file here:

"scripts": {
"prepublish": [ "npm install", "bower install", "gulp clean", "gulp csslint", "gulp jshint", "gulp min" ]
}

Question: Regarding cross-platform: Await/async internally uses i/o compilation ports, which is Windows based. How does that translate in linux/mac with .NET core?

Damian clarified that this statement is not 100% correct. I/O completion ports are a feature of Windows that allows your application when making a Win32 asynchronous I/O call to register for notification of progress changes or completion of that call using an I/O completion port. At that time, you are required to setup and manage the queue to receives that message from Windows. Windows delivers an event notification handle that you can then use to track the status of that call. As an application, you are required to poll those handles to determine the current state of the processes. Damian clarified that the async feature in .NET is only that you have an immediate return of the call and the process will complete and be delivered somewhere else in your call stack, not immediately where it is called.

.NET build a great model on top of this that manages I/O threads for you and those I/O completion ports for you. When you call an async API with the .NET framework, all of these subsystems kick in and manage the Windows processing for you.

To the question: async and await has nothing to do with I/O completion ports itself. On Windows, yes it can and my use this architecture. On Linux there are separate APIs that the .NET framework now uses to deliver this same functionality. To simplify, you could write your own ‘async method’ that returns a task and call Task.SetComplete anywhere else and on any other thread in your application to get the effect without using I/O.

Question: Why is there no up-for-grabs issues on the ASP.NET repository?

At some point many months ago Damian reviewed the issue list to determine what could be labeled up-for-grabs. He believes that the ASP.NET projects are not mature enough to be able to collaborate with community members contributing code for secondary features that are not immediately required. That management of tasks requires additional time investment and a process to manage the pull-requests. The team is not prepared to manage this interaction right now.

Jon suggested that the docs could be marked as up-for-grabs. Damian thinks this is a good idea, and that those items marked with a wrench are items to be built but not necessarily something that the community can take and run with. The depth and detail of these documentation pages is significant and there are full-time team members spending weeks to deliver a single page of documentation. When someone from the team is assigned to build an article and the community can jump in and offer feedback or additional text, this process functions very well.

Question: Is there any plan to distribute .NET CLI through Homebrew?

The team would like to, and they have a PKG. They used to do Homebrew because they depended on Mono and that was easy to do. They probably will.

Question: When would the .NET standard documentation be updated? Especially all of the TFM changes like netstandard and netcoreapp?

There is a doc available on GitHub that the .NET team is actively working on. It’s a hard read, but outlines the direction and current state of things that we are working on.

Question: Did I hear correctly that there are standups for dotnet-cli and dotnet-core?

There are… the On .NET show announces when they are. Scott is planning to help centralize these things, and among them is the centralizing of all URLs. We’d like to see all live broadcasts in one place, and with the team merger we can now do some of those things. Damian chimed in that many of these documentation and public facing interactions with the product are the hard parts that the teams, including Scott’s team, are working on next.

Question: Are there any features in Asp.Net Core that depends on a specific web server? For example the cache flush. If there is do you have a feature matrix showing what server supports what?

Damian knows of only two limitations right now:

windows authentication requires IIS
opaque upgrade of a request to a raw tcp connection as a stream is only supported by kestrel

Some features have native implementations on the web server, so they may run better on one server than another.

Question: What’s the plan for SignalR client code?

The current version, 2.2 has a portable class library implementation and a windows implementation. Damian does not think that either will work with .NET Core properly, but porting that code should be trivial. In RC2 there is a feature that allows you to denote which framework you are targeting and to indicate which portable profile you would like the application to attempt to use as well. This is a bit of an ‘escape-hatch’ to allow portable class libraries to work with .NET Core.

Question: There is a lot of MVC Core project samples in the wild but, but I can’t find simple WebApi starter with authentication and authorization. Is there some boilerplate for it?

The team during the standup offered to research this. However, the team is not shipping a token management server like Identity Server and there are some customers who have indicated that they believe Identity Server is too much infrastructure for simple API scenarios. We would like there to be a template in RTM that allows you to build an API project.

Question: Why weren’t there more ASP.NET Core sessions at Build?

This Build conference was different from previous iterations of the conference. Previously, we had many sessions and a number of them were not well attended. This year we had less sessions and more hands-on workshops in response to feedback about wanting more hands-on code time with Microsoft staff available to assist. That change was a spectacular success with three 4-hour courses run over the duration of the event for 108 attendees each time and long lines waiting to get in. The team did not anticipate the significant interest in the labs since this was the first time it was run at Build. We have plans to improve this experience next time, and the lab materials are available on GitHub if you didn’t get a chance to sit in a lab session at Build.

Question: Is anyone working on an ASP.NET Core on Linux book or video series?

Scott and Damian are going to be doing an MVA video series on building ASP.NET Core without Windows or Visual Studio. Jeff Fritz is working on a book, but we don’t know of any others right now. The ASP.NET Monsters are working on a certification book. If you’re working on a book, please get in touch with the team and we can help you with some content.

Question: I’m having problems with immutable collections in .NET Core…

There is not enough detail in the question to answer, and the team knows it works in Roslyn.

Question: Please fix the Microsoft CDN to add the Access-Control-Allow-Origin: * HTTP header. Its only being served for Bootstrap.

Damian will look further into this…

Question: What about an ASP.NET Core Stackoverflow sub-site for questions?

There already is an ASP.NET Core tag on the standard Stackoverflow site.

Question: Is there a vague schedule for certification exams and MVA content? Scott owns the content for MVA and will move on it and have an idea of a schedule once the RC2 ships and we have an idea of the RTM date.

Question: VS2015 Update 2 crashes with long path names due to node_modules

We have not seen this ourselves, but if you can reproduce it and send a set of steps to Scott to follow-up on.

Question: Is there going to be a demo with the current build like there was last week?

Damian would like to do this next week.

Question: Are there messaging libraries like NServiceBus, MassTransit, WindowsAzure.ServiceBus that are ready for .NET Core?

Not yet, the Azure teams are waiting for System.ServiceModel.Syndication to be completed before they start building on top of it. We don’t know about NServiceBus or MassTransit. Damian encourages you to comment on those projects repos asking for .NET Core support.

Question: How do you run commands/scripts from project.json in the new dotnet cli world?

There’s a new tools section in project.json that will allow you to execute tools from within the context of the dotnet cli using commands like “dotnet tools X” You can also use the scripts block to run command-line scripts when project events occur as described and demonstrated in a previous question.

Question: What happens to dnvm in the .NET CLI? Do we need to specifiy all of the frameworks in project.json or is there still some sort of dnvm?

Dnvm is gone in the new .NET CLI. The CLI has baked into it the same features of the dnvm and will automatically execute the correct version of the dotnet tools based on what version of the framework is used in your application. You no longer need to modify your path to manage the set of .NET CLI tools that you are using.

Comment: With all of the questions about RC1 -> RC2 it might be worth mentioning the cli-samples repo…

Yes, the CLI-Samples repository contains some very small samples that contain the minimum needed to get running on the new CLI.

Question: Where is the best place to fun the latest details on how to upgrade from dnx/rc1 to dotnet/rc2?

This is a tough place to be because the team is only producing daily builds and they are not ready to support this workflow yet. They are working on a document to help make this transition easier, but that is not ready at this time. You can look at the GitHub announcements repository for indications of the breaking changes, but there will be a document in the future

Question: Now that Mono has been contributed to the .NET Foundation, how long will it take the .NET Standard Library to become the one library for everything beyond Core?

Very interesting question…we don’t know. The dream is that the .NET Standard library is the one place to get a framework that runs everywhere. In this model you would use the .NET Standard library the same way you reference the BCL today, or you could install a custom NuGet package.

Question: Will the dotnet cli be used for UWP apps down the line?

Don’t know… no reason it couldn’t, but UWP is a much more graphical interaction experience and that fits in very well with Visual Studio and a full IDE experience.

Question: What does the ‘imports’ section do in the frameworks section of project.json? I see that MVC imports portable-net452+win8

This is what Damian was referencing earlier: the ability of a library to define what target framework NuGet could ALSO include libraries that target. In this case, MVC is compiling and including packages that are also compatible with the portable-net452+win8 target framework.

Comment: Build keynotes were way too long and sessions too short. Hundreds turned away from labs. Would have been nice to have something like Wed: All day .NET/Visual Studio; Thur: All day Azure. And not bounce around between locations

Sessions were an hour, they could have been 90 minutes. This is an interesting idea…

Question: I’m asking (about uwp) for features like being able to reference a NuGet or its source easily and things like tools in project.json

This is a Visual Studio feature that Scott Hunter demonstrated last week in the .NET Futures session.

Question: How can I securely authenticate WebAPIs from C# applications?

We’ll take a look at this topic and put together a blog post on the topic

Question: Loved the new docker tooling stuff demoed at build. I’m having a hard time convincing my company’s infrastructure guys it is a good thing, any insights on how to argument that containers are good from a infrastructure point of view?

We have a getting started with docker series coming to this blog in the next week, with a focus on the docker demo from Scott’s ASP.NET Core session.

Question: I’m busy setting up CI in Visual Studio Online. RC1 Update1, DNXCore50 only. Build keeps failing insisting on building CLR and not CoreCLR. WHY?
This is typically based on the TFMs defined in your project.json file or the environment path is misconfigured to grab the wrong packages.

Question: I see a lot of focus on the shared framework approach in tooling and samples. I’m going the other way right now: I’m a standalone cat! I want standalone native when its available. Will it make RTM, or will it be post-RTM?

Native was cut from RTM and will be revisited after the initial release.

Final Note: There was a question on Twitter after the live standup about the appearance of an RC1-update2 version of the framework. What’s the story with this version?

Damian reports that this is a slight tweak to enable to frameworks to work with the Dev15 Preview release of Visual Studio that was announced at Build. No new features or bug fixes are intended for this version.

Summary

Scott questioned whether this shotgun-style approach of random questions was beneficial as we get closer to a public release, or if a more topic-focused session each week would be more beneficial. We’d like to hear your feedback on the topic, please comment in the discussion area below. Some of these questions will come back as blog post topics that are answered by Microsoft developers or program managers. If you see a question that you’d like to explore further, blog it and send us a note about it and we could mention you in the next ASP.NET Community Standup.

↧

WhereYouAt Demo from Build 2016: Demo Flow and UI

April 7, 2016, 8:35 am

≫ Next: WhereYouAt DemoBuild 2016: Building the Front-end

≪ Previous: Notes from the ASP.NET Community Standup – April 5, 2016

Where You At Demo was a cool little live demo that our team put together for Build 2016. This demo showed off ASP.NET Core applications running in any cloud. Here’s the video of Scott’s session from the beginning of this demo:

Team & Responsibility

Scott Hanselman : Demo visionary and presenter , Azure load balancer, and problem solver.
Steve Lasker : Demo visionary, cloud deployment, containers, Visual Studio Team Services , and API Services
Glenn Condron: API services and Azure Storage.
Maria Naggaga (me): User Interface , HTML5 & JS, and API calls .

Demo Vision

Users visit the WhereYouAt website landing page and see the following:

Logo of cloud on which this ASP.NET Core application is currently running.
A button asking them to provide their location.

Landing Page

The big reveal
The pins on the map represent every person who has participated in the demo. Each color represents a different cloud.

At the bottom of the page are three containers. The containers show the number requests received and allocated per cloud.

Map View

Breaking down the UI

When developing a UI, I found it really helpful to split it into smaller chunks. Doing this helps really helped me identify what I needed to build to do to get the project done.

Identifying the Cloud and Getting Users location

Webtemplate copy From the image above I know, I will need to build the following:

An API call that will identify the cloud that the user was connected to.
A button that will get the users location with their permission.

Populating the Map

To populate the map:

Get the user location and PUT it into an API.
Use those coordinates to pin their locations on the map.

Requests per Cloud

To show the number of request per cloud

GET method to grab the number of requests and separate them by cloud.

Summary

With the user interface and application requirements planned, the team started with their separate specialties to assemble the various components of the demo application. In the next article in this series, I’ll review the user-interface construction.

↧

WhereYouAt DemoBuild 2016: Building the Front-end

April 11, 2016, 8:23 am

≫ Next: Notes from the ASP.NET Community Standup – April 12, 2016

≪ Previous: WhereYouAt Demo from Build 2016: Demo Flow and UI

In my previous post, I went over the user interface and application requirements. Let’s quickly revisit the project requirements:

Get coordinates of the users and identify which cloud the ASP.NET Core app is running on.
Populate maps with custom pushpins.
Display the number of containers running on each cloud.

Get Coordinates

In this app, I am getting the user location with a button using an onclick event handler. In order to grab the user’s coordinates, I used the Geolocation API . Let’s have a look at the code.

Get location

function getLocation() {
    var x = document.getElementById("demo");
    if (navigator.geolocation) {
        navigator.geolocation.watchPosition(showPosition);
    }
    else {
        x.innerHTML = "Geolocation is not supported by this browser.";
    }
}

getlocation() function simply shows the user longitude and latitude every time you load the page. But, in this case, I needed the user’s coordinates to put the pins on the map. To do this we created a simple a location web api that, we can PUT our users longitudes and latitude into.

Store location

function showPosition(position) {
    var lat = position.coords.latitude;
    var lon = position.coords.longitude;
    var xhr = new XMLHttpRequest();
    var params = "latitude=" + lat + "&longitude=" + lon;
    console.log("Params: " + params);
    xhr.open('PUT', '/locations', true);
    xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
    xhr.onreadystatechange = function () {
        console.log("Response:" & this.responseText);
    };
    xhr.send(params);
}

You might have noticed I am using XMLHttpRequest API. XMLHttpRequest API is used to transfer data between the client and Server. In this case, we are using it to PUT the users coordinates into a location API.

Since this was a public demo our team thought it might be a good idea to offset the actual coordinate we were receiving. For most people getting their actual coordinates might feel a little creepy to people . To offset the coordinates we added the toFixed( ) method ; allowing the app to have an idea of where the user is but, not the exact location.

Full Script to get geolocation and PUT it into an API

function getLocation() {
    var x = document.getElementById("demo");
    if (navigator.geolocation) {
        navigator.geolocation.watchPosition(showPosition);
    }
    else {
        x.innerHTML = "Geolocation is not supported by this browser.";
    }
}

function showPosition(position) {
    var lat = position.coords.latitude.toFixed(2);
    var lon = position.coords.longitude.toFixed(2);
    document.getElementById("demo").innerHTML = "You're around Latitude: " + lat + " and Longitude: " + lon;

    var xhr = new XMLHttpRequest();
    var params = "latitude=" + lat + "&longitude=" + lon;
    console.log("Params: " + params);
    xhr.open('PUT', '/locations', true);
    xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
    xhr.onreadystatechange = function () {
        console.log("Response:" & this.responseText);
    };
    xhr.send(params);
}

If you would like to explore the geolocation API , check out theses resources: Navigator.geolocation , getCurrentPosition, and WatchPosition.

Get Location Button

<a href="#" onclick="getLocation();  return false;" class="btn btn-default btn-xl wow tada">Get my Location</a>

Displaying Active Cloud Logo

Include @model directive

@model whereyouat.Settings

Display Cloud Name & Logo

  <h3 id="demo"></h3>
      @{
          var largeIcon = $"~/img/large/{Model.Cloud_Name}.png";
       }
   <h3>You're running ASP.NET on @Model.Cloud_Name!</h3>
   <img src="@largeIcon" alt="@Model.Cloud_Name" />

By including the @model statement at the top of my landing page (Views/Home/Index.cshtml), I am able to specify the type object that the view expects. By using @model directive gives the view access to Cloud_Name through the settings controller .

Results

Pushpins

Start by initializing the map.

var map;
function getLocations() {
       var mapOptions = {
           credentials: "Bing Key",
           mapTypeId: Microsoft.Maps.MapTypeId.road,
           zoom: 3
        };
        map = new Microsoft.Maps.Map(document.getElementById("mapDiv"), mapOptions);

I used the JQuery $.get method to retrieve the user’s coordinates from the location API.

 $.ajax({
                type: "GET",
                url: "/locations",
                dataType: "json",
                success: function (json) {
                    //console.log(json);
                    $.each(json, function (i, entry) {
                        plotEntry(entry.latitude, entry.longitude, entry.cloud_name);
                    });
                },
                error: function (err, status, errortext) {
                    console.log(errortext);
                }
            });

For this demo, we wanted to add custom pushpin the showed not only the users locations but, the logos of the cloud their ASP.NET Core was running one. To do this we used the pushpin class. You can also use the pushpin class to add a default pins.

function plotEntry(latitude, longitude, cloud) {
            //console.log(latitude + ' ' + longitude);

            //Icons for each Cloud Type
            var pushpinOptions = { icon: '/img/' + cloud + '.png', width: 32, height: 32 };
            var pushpin = new Microsoft.Maps.Pushpin(
                new Microsoft.Maps.Location(latitude, longitude),
                pushpinOptions);

            map.entities.push(pushpin);
        }
        $().ready(getLocations);

Result

Number of request per container

For the demo, we had a /cloudcounts api that returns the cloud name, container, and count. The API looked something like this:

{ "cloud_name": "Azure ACS", "container": "185f65604f23"", "Count": 14 }

To obtain the number of request per container , we used a JQuery $.get method similar to what we did to retrieve the user coordinates. The only difference here is, we need to account for the whitespaces in the cloud_name values using the encodeURI function. Looking back to our demo requirements, we wanted to so split the number of request per container by cloud name. It would look something like the image below.

To achieve the above we created three unordered lists; creating an id attribute for each cloud. As I mentioned earlier we used the encodeURI function to account for the whitespaces in cloud_name so, Azure ACS becomes Azure%20ACS. Let’s look at the code

JavaScript

var listoptions = {};

        function getcloud() {

            $.ajax({
                type: "GET",
                url: "/cloudcounts",
                dataType: "json",
                success: function (cloudinfo) {
                    console.log(cloudinfo);
                    $.each(cloudinfo, function (i, entry) {
                        //changes "foo bar" to "foo%20bar"
                        var cloudName = encodeURI(entry.cloud_name);
                        console.log(cloudName);
                        if (!listoptions[cloudName]) { listoptions[cloudName] = "" };
                        entry.container = entry.container.replace("whereyouat-web", "wya-w");
                        listoptions[cloudName] += '<li class="list-group-item">' + '<b>Container:</b> ' + entry.container + ' <br><b>' + entry.Count + '</b> PUTs received</li>';

                    });

                    for (var prop in listoptions) {
                        console.log(prop);
                        //Could use getElementByTagName, but here's how to do it in jQuery as "#foo" doens't work with late eval
                        var listElement = "ul[id='" + prop + "-listview']";
                        $(listElement).append(listoptions[prop])
                    }

                },

                error: function (err, status, errortext) {
                    console.log(errortext);
                }

            })
 }
        $().ready(getcloud);

HTML

<ul id="Azure%20ACS-listview" data-role="listview" class="list-group"></ul>

Results

Summary

In this and the previous post, I went over UI requirements, and how I constructed it. In series of post entitled “WhereYouAt DemoBuild 2016:….” my team is going to cover a variety of topics that include : Load Balancing, traffic managers, and containers. To read these post please visit the .Net Web Development and Tools Blog.

↧

Notes from the ASP.NET Community Standup – April 12, 2016

April 14, 2016, 10:46 am

≫ Next: Notes from the ASP.NET Community Standup – April 19, 2016

≪ Previous: WhereYouAt DemoBuild 2016: Building the Front-end

This week’s meeting is below:

Links of the Week

I think the guys want me to rename this segment to “Jon Loves Community…”, but I think we should re-use the intro song lifted from Mr. Rogers Neighborhood for that. Hmm….

Ben Foster discussed the new JSON patch support in APIs in ASP.NET Core.

Armen Shimoon published an article on using dependency injection to load custom services based on a request

2 new items from the ASP.NET Docs: Layout and Filters Remember: these docs are open source and the team notices who is contributing and is very thankful for their contributions.

DevRadio and Shahed Chowdhuri published a video on Channel 9 discussing Entity Framework on ASP.NET Core

James Chambers posted a reminder about the open source’d AllReady project in the Humanitarian Toolbox. If you want to get started with open source and are looking for a cool project to get started with, check this one out. The ASP.NET and Visual Studio teams kicked off this project as part of the Visual Studio 2015 launch.

Rahul Sahay is starting a blog series on creating a SPA that works with ASP.NET Core and Angular

Julio Avellaneda published a post reviewing the new configuration model in ASP.NET Core

Luke Latham wrote up a tutorial on using ASP.NET Core on Nano Server.

Shayne Bower has a blog post about using Kestrel as a static server for Aggular

Retschgi.com has an article about using ASP.NET with Postgres and Heroku

Mads Kristensen has released a new extension for Visual Studio that verifies web accessibility standards.

Muhammed Rehan Saeed published an article about social taghelpers in ASP.NET Core

Hans Arne Vartdal wrote up how to connect ASP.NET Core with Auth0 bearer tokens

Jon also pointed out RestBus to help with messaging to connect ASP.NET Core, WebAPI, and ServiceStack with RabbitMQ

The Visual Studio blog published information about Salsa, their new JavaScript language service in Visual Studio “15”

Scott encourages everyone to check out these blogs and leave some encouraging comments because these blogs are getting more and more impressive.

Question of the Week:

From Twitter, Grahame Horner asked about some samples demonstrating how to run Kestrel on ServiceFabric.

— Ben Adams helpdully answered by pointing to the weidazhao/Hosting repository on GitHub.

At this point… things took a slight diversion, as Jon turned off his screen-sharing for the community links and Scott noticed that Jon looked a little… different.

Jon Galloway with a new look

Demos

Instead of Questions and Answers this week, Damian and David Fowler shared a demo of using a daily build of the .NET CLI and Visual Studio Code. These items are the current state of things as they are being assembled and are not in their final packaged model ready for shipment and easy installation. Here are the steps with extensive links (updated for this morning’s announcements) so that you can follow along and try it for yourself:

Download the .NET Core SDK from the .NET CLI Github repository appropriate for your machine.
1. Scott noticed Damian’s install of posh-git and the cool command-prompt that it offers.
2. Damian verified that the CLI is installed properly by running dotnet –help
Next, Damian installed the Visual Studio Code editor. In the video, he downloaded the March Insiders Release. However, the 1.0 version of Visual Studio Code was released and you can install that.
Download or clone the ASP.NET CLI Samples repository. You can close it with the git command:
1. ```
git clone https://github.com/aspnet/cli-samples.git
```
Damian navigated his command-line to his new CLI-Samples\HelloWeb folder and ran “dotnet restore” from that location.
Next, the project was built by executing “dotnet build”
The web application was started by calling “dotnet run”. This launched the web server and started hosting this simple web application at http://localhost:5000
This should show a simple “Hello World” page in the browser.
Next, lets look at the editor experience. Open the HelloWeb project folder in the new version of Visual Studio Code.
By default now, Visual Studio Code does NOT come with C# language support and you need to add it. VS Code will detect that you need C# support and prompt you to download it. If yo uwant to grab the latest version of C# support, navigate to the Omnisharp repository and download the VSIX there.
1. If you download a VSIX, install it in Visual Studio Code by using the File – Open command in Visual Studio Code to open the VSIX file you downloaded.
2. This install will look like it isn’t doing anything, but there is an indicator in the bottom-left statusbar of the editor that shows that the install process is taking place. Once this has completed, an indicator will appear at the top requesting a restart of VS Code.
3. Once restarted, you should see the Omnisharp flame in the bottom right statusbar with the name of the project.
4. You should also see that Visual Studio Code will download and install the .NET Core Debugger
Put some breakpoints in the startup.cs file on the app.Run statement and the return statement inside of app.Run
Select the Debugger panel in VS Code, indicated on the left side as a bug with a line through it.
In the debugger panel, choose the .NET Core Launch (console) and click the ‘play’ button to the right of that combobox at the top
Congratulations! You’re now debugging with Visual Studio Code!

This should work on any OS as all of these tools are now cross-platform. Its a big first step for the team to have this complete tooling and framework setup working together properly. Join us next Tuesday as we talk more about ASP.NET

↧

Notes from the ASP.NET Community Standup – April 19, 2016

April 21, 2016, 6:40 pm

≫ Next: Notes from the ASP.NET Community Standup – April 26, 2016

≪ Previous: Notes from the ASP.NET Community Standup – April 12, 2016

This week’s meeting is below:

This week’s standup featured Scott and Damian, with Jon on assignment so our boss Scott Hunter sat in with the guys while they were at the DevIntersection conference in Orlando, Florida this week. Damian took a minute at the beginning to explain to Scott how sunglasses work and then the three set forth on the topic for this week’s standup, which is all about the accomplishments of the dev team this week.

Scott pointed out that regularly featured blogger here on the standup, Shayne Boyer was in the room with them also… and pointed out that Shayne has a fine looking beard. (Transcriptionist note: I think this may be in response to the comment from April 5th when Scott relayed that attendees at Build commented that he had a “weak” beard. If Scott’s isn’t strong, then Shayne’s is Magnus Ver Magnusson)

Damian gave an all-day workshop at DevIntersection, and had the FIRST internal RC2 tooling build since November. This is an important milestone, as the team now has completed tooling and framework builds that can be tested and cleaned for quality. Scott Hunter and Damian had each found some issues with this build and are not yet making this version of the tools public. Damian and Scott Hunter discussed the possible timeframes to complete the quality work on this RC2 version. The agreed projected release of this version could be in the next 4-6 weeks.

Scott Hanselman described the difference between the runtime framework and this tooling release. The tooling is the part that provides the UI and project models and templates in Visual Studio for .NET Core and the other web tools. This also means that the installer and continuous integration process for ASP.NET Core and .NET Core are completely configured and can deliver new builds for testing on a regular basis.

This is a raw build with updates needed to polish the UI. For example, the new ‘New Project’ window now breaks out Web and .NET Core options:

New Project Dialog

A little confusing, but needs some polish before we ship it.

The .NET Core option shows all of the project types that can be built on the .NET Core framework. This means that the ASP.NET Core on .NET Core project type is in this section as well.

These screens lead to a simpler “One ASP.NET template” dialog that is in process of being cleaned up:

One ASP.NET Template Selection

Scott had a package downgrade issue when starting a new project. Closing and reopening the project installed the latest version of the package, and this was an artifact of an older package referencing an older version of a package. As part of diagnosing this, Damian showed that the current ‘New Project’ experience installs packages differently from re-opening a project. Creating a new project grabs a copy of the local packages that were deployed with Visual Studio, optimizing against remote connections to NuGet.org to create a new project.

Scott Hunter showed and started talking about the new static void Main method that is present in the Program.cs file in a new ASP.NET Core RC2 project. That code is below:

This shows that the entry point of the web application is no longer some magic entry point, this is where .NET applications start – in static void main. The web application is compiled to a DLL and the dotnet.exe command-line-interface knows how to locate this method and start the application. This structure allows the application to be portable, as the dotnet.exe is native to the operating system and knows how to load the DLL on its platform. The application can be made standalone, but we need to capture information about the target platform that would be compiled to.

The UseKestrel statement is the webserver for your ASP.NET Core application and it runs in your process. By adding the UseIISIntegration statement, the information from the AspNetCoreModule hosting the process in IIS will pass all of the IIS context information into the Kestrel webserver. This statement runs a noop when executing on a non-Windows platform.

In project.json, there is a new child element in the “dotnet-razor-tooling” that indicates “type: build” to show that this dependency is only needed during build-time and now during run-time. The “type: platform” indicates that the content of that reference should not be copied during a publish operation and should be available with the runtime on a target environment. If the “type: platform” element is removed, the content of the package is copied into the publish target.

Scott pointed out the frameworks->imports element that calls out a number of target-framework-monikers from other platforms like “dotnet5.6″, “dnxcore50″, and “portable-net45+win8″. These are nested on a framework named “netcoreapp1.0″. As that target framework does not yet exist, this imports statement is a lie that you can tell the build process to indicate that the build process can try using these frameworks in packages in the order listed.

The netcoreapp1.0 framework depends on netstandard1.5 which derives from netstandard1.4 and so on back to netstandard1.1 depends on netstandard1.0 which depends on nothing. The team also pointed out that at some point in the future they want to greatly simplify the default project.json so that a basic ASP.NET Core project doesn’t require all of the ceremony of a large project.json file. That’s still to be discussed and planned, and not in the plans for the near future.

Scott Hunter pointed out that this is a journey, and many cool features are coming in the future after the team delivers the first version of the product.

Further down the project.json file, Scott called out the “content” element. Damian explained that this is the collection of folders and files that need to be included in the published output. In a future release, this element will be renamed to publish_include (transcription note: its not clear what the final spelling will be from this video) The scripts element at the end is the same collection of events that you can connect scripts to in order to execute during the publish processes.

Scott asked about an update to the dnvm list command. Damian indicated that its not available yet for RC2, but a spec for a “dotnet runtimes” command is being talked about to deliver this feature in the future. The team wants it to look in the local folder, the user profile folder, and the machine-wide list of runtimes.

Scott Hanselman indicated that the discussions that you saw in this video are a typical day at the office between the teammates. With that, the guys signed off and they’ll be back next week to answer your questions.

↧

Notes from the ASP.NET Community Standup – April 26, 2016

April 28, 2016, 7:39 am

≫ Next: WebForms can Gulp too – Using Node Tools with ASP.NET WebForms

≪ Previous: Notes from the ASP.NET Community Standup – April 19, 2016

This week’s meeting is below:

During the ‘pre-show’ Scott shared that he’s working with ‘the boys’ to build a GameBoy from a Raspberry Pi and a touch screen. Scott also showed us some connectors and a micro-projector he has that enable him to project video from his phone.

Format change: I’m going to be working with Scott to build out an FAQ of typical questions we receive that you can search. We’ve heard that the Q+A segment can drag on, so instead, we’re going to drive more interesting demos.

Damian updated the live.asp.net website using the latest RC2 private tooling build to see how much worked and what the process is to upgrade a simple web application from RC1 to RC2. In this demo, Damian is going to review those changes in the GitHub commit to accomplish this update. The most difficult thing to convert, as reported by Damian was the update of a TagHelper that would handle Html.Partial calls by reaching into the ViewEngine. This is not a typical implementation, and most people will not have that.

Damian started by updating the project’s local NuGet.config file to reference the nightly build feed of ASP.NET Core. This ensures that he will install the latest RC2 versions of packages that are available and been through some testing on the Microsoft CI services. Similarly, he updated global.json to reflect a new version of the framework.

A side goal of this update was to convert from .NET Framework to .NET Core and Damian found a few libraries that were not yet available in .NET Core. To get these libraries updated, he used a new feature in the project.json notation to effectively lie to NuGet about which framework the project was built with. In the frameworks element of project.json, Damian added the imports element with some portable target frameworks in an attempt to get dotnet to compile and run with the libraries he was using previously.

A major change to the code was to change all namespace references from *AspNet* to *AspNetCore*

The most noticeable change to the structure of the project is the introduction of the Program class with the public static void Main method. Starting with ASP.NET Core RC2, web projects are formatted and structured similar to console applications. The Main method is the entry point for the application and boots the ASP.NET host. That host gives you the dependency injection and runs your startup class. At the point that the Main method calls host.Run(), the web application launches and takes control of the process. The process now looks like the following:

Environment variable names changed, and now begin with “AspNetCore_” instead of “Hosting:”. You can see this change in the live.asp.net launchSettings.json file. Visual Studio uses this file to determine how to configure and start the environment when debugging. The environment variable separator was changed from a colon “:” to an underscore “_” to better support Linux and Powershell. If you use a double-underscore “__” in your variable name, it will create a hierarchy in the configuration.

There are other changes made to accommodate the change from the .NET Framework to the .NET Core Framework. One such change accounted for the lack of a ConvertTimeUtc method on the TimeZoneInfo object by calling the ConvertTime method with the UTC timezone. Another change Damian detailed is the lack of a Stream opening with a pathname. To get around this limitation, Damian creates StreamWriters and StreamReaders by passing in a File.OpenWrite() argument to their constructors. Scott and Damian questioned why some of these overloads are dropped between .NET Framework and .NET Core, and those questions are being heard and discussed by the team.

Most of these API changes had announcements declaring the breaking change in the issue list of the GitHub ASP.NET Announcements repository. During this period of daily builds, we recommend you reference this list of changes to help identify where your code will need to be updated.

There were a number of other API / namespace rename operations that were done as part of the polish being applied in preparation for RTM. Some of these that Damian highlighted include:

Introducing the ContentRootPath
Configuration is now of type IConfigurationRoot
The new templates require calling AddAuthentication in the ConfigureServices method.
A decision was made to configure dependency injection with delegates and to configure ASP.NET middleware with instances of classes.
TagHelpers have improved support for enums in markup

This post is a quick dump of the process Damian went through. There is a formal document coming from the team that details how to do this migration. Join us every Tuesday, and we’ll discuss more about ASP.NET.

↧

WebForms can Gulp too – Using Node Tools with ASP.NET WebForms

April 29, 2016, 4:34 am

≫ Next: Building accessible websites just got a lot easier

≪ Previous: Notes from the ASP.NET Community Standup – April 26, 2016

Visual Studio 2015 brought a set of tools into the IDE from the Node environment that are great for web developers to use. Many folks who build JavaScript applications or single-page-applications were eager to see the introduction of these tools to Visual Studio. Can the tried and true ASP.NET Web Forms framework use Gulp, npm, bower, and the Task Runner Explorer? In this blog post, we’ll take a look at how we can replace the ‘out of the box’ use of the Script Manager in a Web Forms app with these node-based tools.

Why Not Use ScriptBundles?

ScriptBundles and StyleBundles are a great tool that allow you to configure and deliver resources to your visitors in a compressed package to reduce or even eliminate extra requests to your web server. These features allow you to define a bundle of resources in an xml-based config file or configuration classes like BundleConfig.cs This approach, while easy to configure, requires the web service execute server-side code in order to configure and deliver these resources. The alternative approach described below, completes this work one time during the build process and delivers static files every time to the requestor. This approach will also prepare your assets for use on Cordova, WinJS, or ASP.NET Core where you don’t have the bundling capabilities. Finally, because we are using package managers to manage our scripts and styles, we can get new versions with fixes and features installed easily with the help of these tools.

Introducing npm, gulp, and bower

Gulp Bower Npm logos These three tools provide the building blocks for browser-side coding in our application. Let’s take a quick look at each tool and what it does:

npm is the Node Package Manager. This is the NuGet equivalent in the Node platform and can install other Node tools and components, including the other two listed below.
Bower is another package manager that delivers static content like CSS, Images, JavaScript, and Fonts.
Gulp is a task runner that can be used to ‘build’ your browser-side resources for delivery to your visitors. It can be used to automate other tasks, but provides a great JavaScript-based framework and toolset to automate your repetitive tasks.

This walk-through focuses on the default ASP.NET 4.6 template and converting those resources to use this acquisition and build mechanism.

Step 1 – Configure npm

Nope.. Step 1 is not install NodeJS, because if you’re using Visual Studio 2015 its already installed for you in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Web Tools\External We can move forward and start configuring the node package manager for our project. In the Visual Studio Solution Explorer window, Add a New Item to the base folder of your project, and choose npm Configuration File. You’ll probably notice that the other configuration files we’re going to use are in the list as well: Bower Configuration File and Gulp Configuration File. Go ahead and add those to your project as well.

Starting with the package.json file, we can see that there isn’t a lot in the base file to start. Thanks to the intellisense features built into Visual Studio, we’re going to get some help in building out the list of devDependencies at the bottom of the file.

Inside of the devDependencies block, lets enter a JSON name-value pair for the gulp package. As you start typing “gulp”: the Visual Studio editor should begin showing some intellisense hints of the list of packages and versions available. Choose the latest version of Gulp, and lets also add references for the gulp-concat, gulp-cssmin, and gulp-uglify packages. My package.json file looks like this:

You can now right-click on the package.json file in your solution explorer and choose to ‘Restore Packages’ and Visual Studio will run the npm install command to acquire and make these packages available to you in a new “node_modules” folder.

Step 2 – Configuring Bower

Since we already added a bower.json template in the previous step, we work with that file to begin adding package references to match those that were installed by NuGet into our project. There are two ways to do this: right-click bower.json and open the bower package manager UI or you can edit the bower.json file by hand. In both scenarios, you need to add the bootstrap, jquery, modernizer, and respond packages to your configuration. In my bower.json file, I added the matching version numbers of these packages so that they match the default version numbers in the ASP.NET template:

If you keyed in the package names like I did, you can perform a similar right-click action on the bower.json file to restore packages. This will create the bower_components folder in your project folder and fill it with the files from these packages.

Step 3 – Configure Bootstrap and My CSS with Gulp

Next, we need to write some JavaScript in the gulpfile.js file to dictate the tasks that need to be accomplished to build our client-side resources. The initial gulpfile starts with a line to require(“gulp”) and we will need to require those other gulp-* libraries that were referenced by npm. Those lines will look like the following:

Initial Gulp references

Next, start writing the gulp task called “min-css” with the following content:

The task is defined with the task method on the Gulp object, submitting a name for the task and an function that should be executed for this task. Each step of this task’s function is a call from the gulp object through a series of pipes. In Gulp, content is piped from one step to the next using the pipe function. The first steps on lines 14,15 grabs the contents of the Bootstrap fonts folder and copies it to the fonts folder in the project. The second step on lines 17,18 does the same thing with the JavaScript files for bootstrap. The final steps in lines 21-25 do some extra steps besides copying content. In this last step, the contents of the bootstrap.min.css file and the site.css file are to be processed. These two files are marked up in the src method as an array of strings and are then piped into the concat command. Concat will take the contents of the pipe and combine them into one file at the location submitted, in this case the Content/site.min.css file. Those contents are then passed into the cssmin function which will optimized the content of the CSS files by eliminating spaces, tabs and comments. This makes it smaller for transport and easier to download 1 file than multiple files. The final method, gulp.dest indicates that the results of the cssmin operation should be written back to that site.min.css file. At this point, we can run this step in the Task Runner Explorer window in Visual Studio by right clicking on the ‘min-css’ task on the left side and choosing Run. This will run the task in the extra window pane of the Task Runner Explorer, and you should quickly have Bootstrap configured with a minimized CSS stylesheet at site.min.css Step 4 – JavaScript Configuration The JavaScript processing is a little more involved than the CSS, but reuses some of the same tasks we just learned about.

This time, we’re going to assemble a collection of these files into one JavaScript file. For each of these five steps, we’re going to move files into the Scripts folder. For the jQuery, Modernizr, and Respond libraries it’s a straight copy into the Scripts folder. With the MSAjaxBundle and WebFormsBundle, we’re going to take some steps before copying. These two bundles are originally added to your project through NuGet packages and bring a significant number of JavaScript files to your project. Let’s do something to simplify that.

Each of these steps for MSAjaxBundle and WebFormsBundle collects a group of JavaScript files by using a wildcard in the src function. They then pipe those contents into the concat function to make one big JavaScript file named MSAjax.min.js or WebForms.min.js accordingly. The contents of those files are then piped into the uglify function, a function that minifies JavaScript by eliminating spaces, comments, and reduces the name of variables in JavaScript to a single character. Finally, those contents are saved back to disk in the same way that our CSS was with the gulp.dest method.

We can now run this js task in the Task Runner Explorer window and see it produce the five JavaScript files for our project:

Step 5 – Update the Master page

In the Master page, you can remove all references to the bundles and replace them with direct references to the scripts and styles:

You can also remove the configuration of bundles in the App_Start\BundleConfig.cs file to reduce some processing at application start up.

This is nice, but what happens when I add more to that site CSS file? I need to re-run the min-css step, where ASP.NET would just recompile it each time.

Step 6 – Configure Gulp-Watch

You can configure gulp to watch files for an update and when that update occurs, trigger tasks to be processed. This feature can be activated with the watch method on the gulp object. I like to create a task called simply watch and have that task run in the background while I code. Here is the code for my watch task in this project:

This method takes an array of file globs and an array of tasks to execute if it detects a change in any of the files referenced. Now, when I change my site.css file, the minified version is regenerated very quickly. The Task Runner Explorer makes this even easier to use, because I can bind my watch task to the ‘Project Open’ event so that the tasks runs whenever I open this project. To enable this event binding, right-click on the ‘watch’ task in the Task Runner Explorer and choose “Bindings – Project Open”

Summary

This is just the beginning of a journey into the Node toolset for ASP.NET web forms developers. There are many different ways to configure scripts and tasks to run against your project to automate many repetitive tasks. What are some of your favorite packages and tips for managing JavaScript, CSS, and other resources in your project? Let us know in the discussion area below.

↧

Building accessible websites just got a lot easier

May 2, 2016, 2:19 pm

≫ Next: Notes from the ASP.NET Community Standup – May 3, 2016

≪ Previous: WebForms can Gulp too – Using Node Tools with ASP.NET WebForms

When building websites it is important that it is accessible for everyone that needs to use it. Implementing web accessibility features greatly helps to achieve that. Here’s what the W3C has to say about that:

Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web. Web accessibility also benefits others, including older people with changing abilities due to aging.

The W3C continues to explain why it is important:

The Web is an increasingly important resource in many aspects of life: education, employment, government, commerce, health care, recreation, and more. It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with disabilities. An accessible Web can also help people with disabilities more actively participate in society.

It’s also good for business. For instance, if you run a web shop then you want to make sure that the largest number of people are able to purchase your products.

However, building websites that conform to accessibility standards such as WCAG 2.0 (by the W3C) or Section 508 (for US government compliance) has traditionally been rather cumbersome and required use of 3^rd party web services such as the Wave Accessibility Checker. It is a disconnected experience that doesn’t provide a natural workflow for web developers. Instead, what is needed is a way to make accessibility features natural and easy to implement for web developers as part of their regular development process.

Enter Web Accessibility Checker!

This Visual Studio extension utilizes Browser Link for ASP.NET to run standards based accessibility checks on the live running website. There is no project specific setup required to make this work. Simply install the extension and run the website in any browser.

Under the hood, the extension uses the axe-core JavaScript library to perform the accessibility checking. The supported standards it checks for are:

WCAG Level A
WCAG Level AA
Section 508
Other best practices

When the extension finds any accessibility errors it displays directly inside the Error List window.

The accessibility check can either run automatically when ASP.NET projects are run in the browser (F5 or View In Browser) or when manually invoked (Ctrl+Shift+M).

When manually invoked, the extension will run the accessibility check on all browser instances that currently has the web project loaded. So if different pages are loaded in different browsers, the Error List will be populated with the combined set of errors.

If you haven’t already, go download Web Accessibility Checker and try it out. It works for any ASP.NET web project where Browser Link is able to connect. As usual, this extension is open source on GitHub.

↧

Notes from the ASP.NET Community Standup – May 3, 2016

May 9, 2016, 11:17 am

≫ Next: Introducing the IIS Administration API

≪ Previous: Building accessible websites just got a lot easier

This week’s meeting is below:

Links of the Week:

Tony Sneed commented on Twitter about getting a nightly build of RC2 running with Docker.

Anthony Chu deployed ASP.NET Core to Docker Swarm with container service

Scott Sauber shows us how to use feature-folder structure instead of separate Model, View, and Controller folders

Chris showed us how he writes a cross-platforms single page application with Angular and Typescript

ASP.NET Monsters covers the Developers Pages in ASP.NET Core

James Chambers shows us how to do GitHub authentication in ASP.NET Core

Damien Boden wrote up how to make Angular 2 localization work with ASP.NET Core

Charles Nurse talks about building an API for his new blog platform based on ASP.NET Core

How to use StormPath for authentication and authorization in ASP.NET Core

Shawn Wildermuth shows how to implement a logging provider in ASP.NET Core

Steve Smith is offering online training classes in June 2016

Steve also published an updated error handling document in the ASP.NET docs

Mads Kristensen shared a post about the web accessibility plugin for Visual Studio

An extension to help make Stackify easier to use

Jeff Fritz wrote a post about using gulp, npm, and bower with Web Forms

Mahesh shows us how to use multiple objects as input parameters in an MVC action method

Nick Craver from the Stack Overflow team wrote about how they deploy their service

Demo

Today’s guest is Sébastien Ros who works on MVC team, also works on the Orchard project. He has been recently working on Orchard v2 that is based on ASP.NET Core and using this migration as a good test of the migration process. In the week prior, one of the Orchard team members was able to run a modified version of Orchard on Linux.

Sébastien showed us the setup screen and created an initial tenant on an Orchard installation running on Linux. Orchard uses separate folders for each tenant that it hosts, to allow separate configurations to be stored. He also shared that Orchard v2 in its current state without caching, is faster than the optimized Orchard v1 on Windows.

Currently, the Orchard team is using Dapper with the YesSQL document database. The team is ready to start using the new ICacheService and IDistributedCache services in ASP.NET Core with the project. They also have built out what they call “Shape Caching” in Orchard that allows them to cache parts of pages, similar to “donut hole caching”.

Sébastien then showed us how TagHelpers are being used in Orchard to replace C# based HTML Helpers with tags. This helps to make the HTML templates in use by Orchard much easier for designers to consume, as they do not need to know C# syntax to work with content. Additionally, they have developer a dynamic tag-helper capability where new tag helpers are generated based on new content types added to the Orchard system. This generation of tag-helpers happens through a TagHelperDescriptorResolver, the source for the Orchard ShapeTagHelperDescriptorResolver is available on GitHub.

Scott asked Sébastien about the challenges they had in migrating from ASP.NET MVC to ASP.NET Core. Damian pointed out that this was a double migration: from ASP.NET MVC to ASP.NET Core and also from .NET Framework to .NET Core. They had to do some work to get their dependency injection framework operational, as they manage scope objects per tenant in the system. He indicated that it was not hard to migrate the system, but some of the customization they did for logging caused some challenges in migration because logging is just part of the platform in ASP.NET Core There were no blocking items in the migration, and 90%+ of the work on Orchard is contributed from the community with most of the changes to support ASP.NET Core actually coming from the community contributors.

Scott and Damian discussed how to get Orchard running in a production web space for the internet to access. There is currently reverse proxy documentation for ASP.NET Core with Linux available in the ASP.NET docs.

We recommend that you check in Tuesday May 10th, as there are some significant updates from this week to discuss about the schedule.

↧

Introducing the IIS Administration API

May 9, 2016, 11:53 am

≫ Next: Notes from the ASP.NET Community Standup – May 10, 2016

≪ Previous: Notes from the ASP.NET Community Standup – May 3, 2016

The IIS team has been working on a new RESTful API to manage your IIS configuration. While still under development, the team was eager to share a preview of the new API. The API allows configuration of IIS resources such as authorization rules, modules, and applications.

IIS Rest API Sample

The API has been built with Hypertext Application Language (HAL) to allows APIs to have built-in discoverability. Starting at the root of the API, you can browse the entire API surface.

In addition to the API, the IIS team has also built an API explorer that makes it easy to browse the entire API surface.

Head on over to https://jimmyca-srv2.cloudapp.net:55539 and use the access token OgMks6N7CtZTptX2DTnLe8JvkmATOuqw1ZJnZzK1RojeYs251Wlfvg to check out the API explorer.

If you want more information visit the IIS blog at https://blogs.iis.net/adminapi/ and watch that space as the IIS team continues to post updates.

↧

Notes from the ASP.NET Community Standup – May 10, 2016

May 11, 2016, 9:46 am

≫ Next: Announcing ASP.NET Core RC2

≪ Previous: Introducing the IIS Administration API

This week’s meeting is below:

No Jon Galloway today, but Scott and Damian wanted to handle as many questions about the recent announcements. Oh, and it was Damian’s birthday… so everybody be nice to him on his 29th birthday (again!)

Announcements:

The announcement of the runtime / tooling split was issued on Friday with the release schedule announced. First: .NET RC2 runtime and libraries will ship in mid-May. This release includes “anything you would put in your bin folder” Damian described the ASP.NET stack as the following:

The stack of projects that make up ASP.NET Core

Projects are locked down from the bottom up, and the “bug bar” is raised as each layer locks into place. Damian previously described the Microsoft methodology for delivering the stack, and the bottom three layers of this diagram are in escrow. There are candidate builds for those, and they will not be changed unless there is a significant ‘escrow-breaking’ issue found. The ASP.NET libraries had 5 issues needing to be repaired, and could have a candidate build ready by the time you read this. The Visual Studio layer had 12-15 issues remaining that could be completed by the end of the week.

Once the verification of these completed features is done, the team starts deploying the packages to NuGet.org, blog posts, documentation, and website updates need to be deployed. Scott pointed out that he has been working on a new website to make it easy for developers to get .NET He has even acquired a cool URL for this new site, and was given clearance to announce that site is dot.net Scott is currently working on the new version of that site that will provide a unified getting started experience.

The tooling, command-line experience that replaces dnx/dnvm/dnu, the Visual Studio tools, and the Visual Studio Code C# extension will be delivered as Preview 1 with the RC2. A follow-up Preview release will be issued with the RTM in late June. The quality of the libraries has been very high since the release candidate in November, and they continue to be very good. However, the tooling is much newer with the re-platform on top of the .NET CLI and has some rough edges. There are changes coming in the tooling, but the runtime APIs are not changing prior to RTM.

A few things have happened in the .NET development story since the RC1 release. Xamarin was acquired and is now part of the Microsoft .NET development experience. Customers want to be able to share code between project types, and this capability was not designed into the server-focused initial build of ASP.NET Core. The foundation of these other project types is MSBuild.

There are some issues with the MSBuild experience, including the requirement to use the Visual Studio IDE to work with a build file productively. We want to ensure that the effort to make the project file ‘human-editable’ as in project.json persists with the new MSBuild model that ASP.NET Core will begin using. We want to ensure that there is still a great experience working with this file in lightweight text-editors, and that is part of the work that will be done on this experience after the RTM of the Runtime libraries.

The other thing that we have learned is the Linux and Windows Nano have been a bigger driver for developers to migrate from .NET to .NET Core. Very large customers and very large solutions have raised concerns about the migration of an existing codebase to .NET Core. There will be some focused blog posts coming in the weeks ahead to discuss the enhancements that we plan in order to accommodate this type of migration.

The goal of this project is that dotnet should be dotnet, and you as a developer should not think about a flavor necessary to get it running on your hardware or your operating system. We want developers to only need to think about code, and everything else needed to manage that experience is just noise.

Scott asked if there were any problems created by this split. If you were using the RC2 nightly builds, you will see a breaking change with the NuGet package renaming to “Preview” for the tooling packages. You will have to clear your NuGet package cache to reset things. This can be accomplished:

On Windows, use the nuget.exe command (download here) and execute “nuget locals all -clear”
On Mac and Linux, enter your ~/.nuget/packages folder and clear the contents

In RC2 / Preview 1, there will be no change. In RTM / Preview 2, the only change you will see if the xproj files will be renamed by Visual Studio to a csproj. From that point on, project.json will live next to csproj. The team will then begin migrating features from project.json to the csproj file. Its possible that the project.json file remains, and contains all of the package references for NuGet and is renamed to nuget.json. The team has already tested some work that shows you will not need to list all of the files in your project file, one of the key benefits of the project.json model.

Questions

Question: Will SignalR still “unofficially” work?

Not sure of the current status, but it is one of the top priorities after the RTM.

Question: Do we have any commitment or knowledge from Azure team as to how long after RC2 release (or RTM for that matter) will PaaS components will support it?
The Azure team is working with the ASP.NET Core team, and this should be ready very soon after each release. Scott suggested that the two of them record the upgrade process for a web application as a demo.

Question: project.json is going away? Sadface

What were the things we liked? It was small, contained NuGet information, and could be edited by hand. Damian does not want to lose any of those benefits, and that is why they are working in several steps to complete this migration. Additionally, the team is building tooling at the command line so that you don’t have to work with the project file directly. Consider a possible npm-like command like “dotnet install json.net –save” to add a NuGet package to your project. There will be first class commands like this available.

The new MSBuild will not have a complete list of every file, so that should reduce the size of the build file. It will still be XML, but the team is committed to making that experience better for all .NET projects. This will be an enhanced MSBuild that has all of the best parts of project.json

Question: Will RC2 completely remove DNX?

Yes, it will not remove it from your system. It will no longer be required by the Visual Studio and .NET experience.

Question: Is RC2 the time to start working on production-worthy projects?

That’s up to you based on the tolerance you have for changes leading to RTM. We would like you to build with the RC2 to help identify issues that need to be addressed for RTM. The tooling may be rough and your feedback about that will help improve it prior to the tooling RTM.

Question: Is MSBuild open-source?

Yes – https://github.com/Microsoft/msbuild and Xamarin runs on MSBuild as of the Evolve 2016 conference.

Question: Sometimes when pulling libraries for RC2 bits we would see RC3 in some package names. Are these just naming bugs, RTM libraries, or something else?

That’s a dev feed that you’re hitting, and they needed to name the newest version of something when working on the ‘next version’ of something.

Question: Is it normal for dotnet watch to be slow, at least 30 seconds until recompile and server restart

The team has made some performance improvements in this area, and we hope that you aren’t seeing this performance in the future. They are not as fast as RC1, but 30 seconds is too long. Try again with the impending RC2 release.

Question: Will it be easier to point IIS at your wwwroot folder and just run without publishing?

This is how IIS express runs with Visual Studio. You can do this. But we don’t recommend you do it for production.

Question: Since the conversion tooling from legacy .NET to .NET Core is not ready, is it possible to mix .NET and .NET Core in a single application? If so, how do they communicate with each other?

It is possible, with the assumption that the same “app” is hosted on the same web application at “www.myurl.com” that hosts different .NET applications mapped with different IIS modules. The trick for you will be to figure out how to share state between the .NET Core and non-.NET Core projects.

Question: Can we deploy ASP.NET Core 1 to Azure Web Apps

We’re working on that now.

Question: Is the Azure Service Bus Client Library available for .NET Core?

This library is blocked on a dependency on System.ServiceModel.Syndication. The team is working on that port, and does not have a firm timeline.

Question: It doesn’t seem to be possible to receive model data from both form or json body. But from what I can tell it works in older versions of ASP.NET

This had been removed as a security concern to prevent a potential injection of content with a cross-site request forgery attack. You now need to declare where you expect the content to be coming from.

Question: Will it be possible to run windows commands in bash?

No… you can’t run Windows commands from bash, but you can run scripts that execute in a windows process.

Question: Will RC1 projects that run on mono still run via the dotnet command?

Not sure… in theory it should work.

Question: I’d like to see a demo of remote debugging with IIS

Sure… we can do that

At this point, our boss “called in to the show” and Scott took the call. From Scott’s phone, over the hangout we heard “we have dates!” There is lots of excitement around the upcoming RC2 release, and the team can’t wait to share them with you. Join us next week on live.asp.net and we’ll talk more about the RC2 release.

↧

Announcing ASP.NET Core RC2

May 16, 2016, 9:40 am

≫ Next: Announcing WCF Connected Service for .NET Core RC2 and ASP.NET Core RC2

≪ Previous: Notes from the ASP.NET Community Standup – May 10, 2016

We are very pleased to announce the availability of ASP.NET Core RC2. This release succeeds the ASP.NET 5 RC1 release and features a number of updates to enhance compatibility with other .NET frameworks and an improved runtime. You can install the RC2 from http://dot.net.

What happened to ASP.NET 5?

This release features the rebranding of ASP.NET 5 to ASP.NET Core. This renaming was made in order to clarify that this is a new framework built from the ground up and not a revision of the existing ASP.NET frameworks. More details can be found on this blog.

The release contains the RC2 of the .NET Core runtime and libraries. These libraries are everything that ends up in your ‘bin’ folder when you deploy an application. The tooling included (command-line tools, project tools, and Visual Studio tools) has been declared as a preview 1 release. This change allows those developers who are comfortable with using the runtime to move forward with their projects while the ASP.NET Core tools are completed.

Introducing the .NET CLI

A key change that occurred between RC1 and RC2 is the introduction of the .NET command-line interface. This tool replaces the dnvm, dnx, and dnu utilities with a single tool that handles the responsibilities of these tools. Get started by executing the command `dotnet` at a command-prompt:

You can learn more about the .NET CLI on the .NET team blog and their coverage of this update.

ASP.NET Core is a console app

In RC1 an ASP.NET application was a class library that contained a Startup.cs class. When the DNX toolchain run your application ASP.NET hosting libraries would find and execute the Startup.cs, booting your web application. Whilst the spirit of this way of running an ASP.NET Core application still exists in RC2, it is somewhat different.

As of RC2 an ASP.NET Core application is a .NET Core Console application that calls into ASP.NET specific libraries. What this means for ASP.NET Core apps is that the code that used to live in the ASP.NET Hosting libraries and automatically run your startup.cs now lives inside a Program.cs. This alignment means that a single .NET toolchain can be used for both .NET Core Console applications and ASP.NET Core applications. It also means that customers have more obvious control over the code that hosts and runs their ASP.NET Core app:

Program - Main in ASP.NET default template

In this code snippet, from the Main method of an ASP.NET Core RC2 app, is responsible for configuring and running the app. If, for example, you want your application to listen on a particular port or IP address then you can use the WebHostBuilder to do it.

This migration from a class library that is designed to be run on the DNX to a console application with a Program.cs and a Main method that can be run by a new .NET toolchain is one of the most significant changes that RC2 brings to ASP.NET Core.

IIS Support Baked In

IIS is a tremendous web server and we continue to provide first-class support for it. Use the new ASP.NET Core Module in your web.config (it’s added in the new project templates) to configure IIS to launch and host your application.

<configuration>
<system.webServer>

  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
  </handlers>

  <aspNetCore processPath="%LAUNCHER_PATH%"
              arguments="%LAUNCHER_ARGS%"
              stdoutLogEnabled="false"
              stdoutLogFile=".\logs\stdout"
              forwardWindowsAuthToken="false"/>
</system.webServer>
</configuration>

How do I migrate from RC1 to RC2?

With these changes to the underlying framework and the branding changes, there are a number of updates that you will need to make to your applications to make them RC2-ready. We have written the following guides to help you update:

Can I use RC2 with Azure Web Applications?

We are rolling the RC2 out to the Azure App Services and expect it to become available later this week. Keep an eye on the Azure Blog for an announcement when it is available.

Summary

There are a number of other changes that occurred in order to clear up, fix, or simplify APIs during the RC2 development process. There are also a number of performance enhancements that were committed in this release, most notable are those that significantly improve the throughput of the Kestrel web server. As always, you can find clear documentation of all ASP.NET Core RC2 changes in our Announcements repository on GitHub. Please download a copy of ASP.NET Core RC2 today and give it a try.

↧

Announcing WCF Connected Service for .NET Core RC2 and ASP.NET Core RC2

May 25, 2016, 12:08 pm

≫ Next: Announcing a new .NET and ASP.NET Core Bug Bounty

≪ Previous: Announcing ASP.NET Core RC2

With the availability of .Net Core RC2 and ASP.NET Core RC2 we are pleased to announce an update to the WCF Connected Service Preview for ASP.NET 5 Visual Studio extension tool for generating SOAP service references for clients built on top of WCF for .NET Core RC2. This update brings some improvements to the user experience when navigating through the Connected Service wizard UI and the ability to reuse types defined in the project to which a service reference is being added to and from the project’s references, in addition to several bug fixes.

How to Install the extension

The WCF Connected Service extension can be installed on Visual Studio 2015 and it has the following prerequisites. Please make sure you have prerequisites installed before installing the extension.

Notice that the previous version of the WCF Connected Service extension is not compatible with .NET Core RC2 and once you upgrade it cannot be reinstalled since it is being replaced with this new version of the tool. We strongly encourage you to upgrade to .NET Core RC2 and get this new and improved version of the extension installed.

As with previous versions of the extension, it is published into the Visual Studio Extensions Gallery and can be downloaded either from the official Visual Studio Extensions Gallery download page or directly from Visual Studio via the “Extensions and Updates” dialog as shown below by searching for “WCF Connected Service” for instance.

How to use the extension

The WCF Connected Service extension is applicable to any projects created with project templates under Visual C# -> .Net Core. This includes Console Application (.Net Core), Class Library (.Net Core) and ASP.NET Core Web Application (.Net Core) as shown in the image below.

Using the ASP.NET Core Web Application project template as an example, I will walk you through the steps to add a reference to a WCF service to the project:

1. In Solution Explorer, right-click on the References item of the project and then click Add Connected Service. The Add Connected Service dialog box appears as shown below.

2. In this dialog, click Microsoft on the left column, then click WCF Service – Preview in the middle column, you might need to scroll down a bit, and finally click on the Configure button. This will bring up Configure WCF Service Reference dialog box.

3. You can either click the Discover button to initiate a search for services that are contained in the current solution or enter a service URL in the Address box and then click Go to search for services hosted at the address. The services that are found will be displayed in the Services box and you can select the one you want to use. You can also enter the namespace that you want to use for the reference in the Namespace box.

Once a service has been selected you can click Next to visit the Data Type Options and the Client Options pages; alternatively you can click Finish to use default parameter values.

One of the novelties for this release is the ability to reuse types defined in the project and types from assembly and project references. This is a very popular feature in the Visual Studio Add Service Reference tool for traditional .NET Framework projects that was missing in previous releases. This is useful when types used for creating the service you are adding a reference to are available to your project, some of these types might be defined in .NET Core framework assemblies for instance, and in order to avoid type clashing it is necessary to reuse the existing types.

4. Click Finish when you are done.

This will download metadata from the WCF service, generate a reference.cs file for the WCF client proxy, and add it to your project under the Service References folder. The project’s project.json file will also be updated with the NuGet package references required for your project to compile and run on the target platform.

You can then create instances of the WCF client types generated by the tool and communicate with your web service as desired.

What’s next and feedback request

This is a preview version of the tool. We are working to improve it and bring in more features in the future. In the meanwhile, we would love to hear about your experience using this tool and any feedback you can provide, including issues you may find, as well as features you would like to see implemented in the tool.

Thank you and happy coding!

↧

Announcing a new .NET and ASP.NET Core Bug Bounty

June 7, 2016, 10:00 am

≫ Next: Notes from the ASP.NET Community Standup – June 2, 2016

≪ Previous: Announcing WCF Connected Service for .NET Core RC2 and ASP.NET Core RC2

Now that you’re all updated to RC2 I am pleased to announce a further 3 month bug bounty program for .NET Core and ASP.NET Core, our cross platform runtime and web stack. The program encompasses the RC2 and, should its release fall within the 3 months programme period, the RTM version. The bounty will run from 7th June 2016 till 7th September 2016.

During the RC1 bug bounty we received quite a few interesting bugs which we’d addressed, including one which prompted an entire rewrite of a feature to make it easier for developers to use successfully. It’s been a great source of pleasure for me to to reward and recognize security researchers for their hard work in discovering and reporting these bugs and I look forward to doing the same for any qualifying security bugs that follow in the next 3 months. As before we consider bug bounties a win-win, as it is both is the right thing for our customers and for the security researcher community.

The bounty includes both the Windows and Linux versions of .NET Core and ASP.NET Core, and includes Kestrel, our new web server.

https://dot.net/ has instructions on how to install RC2 on Windows, Linux and OS X. Windows researchers can use Visual Studio 2015, including the free Visual Studio 2015 Community Edition. The source for .NET Core can be found on GitHub at https://github.com/dotnet/corefx. The source for ASP.NET Core can be found on GitHub at https://github.com/aspnet.

We encourage you to read the program terms and FAQs before beginning your research or reporting a vulnerability. We would also like to applaud and issue a hearty and grateful thanks to everyone in the community who has reported issues in .NET and ASP.NET in the past. We look forward to rewarding you in the future as we take .NET and ASP.NET cross platform.

Further information on all Microsoft Bug Bounty programs can be found at https://aka.ms/BugBounty and in the associated terms and FAQs.

↧

Notes from the ASP.NET Community Standup – June 2, 2016

June 8, 2016, 9:54 am

≫ Next: A Peek into .NET Open Source Contributions

≪ Previous: Announcing a new .NET and ASP.NET Core Bug Bounty

This week’s meeting is below:

Scott Hanselman was unable to join us this week, but Scott Hunter joined us for some updates and to answer some questions that have been raised since the RC2 release. Since it has been a few weeks since our last video, Jon had a generous collection of community content to share:

Links of the Week

Mehul Harry announces the DevExtreme TagHelpers now support ASP.NET Core RC2.

Jonathan Mezach overviews the .NET Platform Standard and shows how to use “imports” to include libraries that don’t target a specific netstandard version.

Here’s an intersting e-commerce system by Thien Nguyen Le Quynh that’s based on ASP.NET Core targeting Windows and Linux using SQL Server and PostgreSQL.

Jerrie Pelser shows how to use environment variables and the Secret Manager tool to avoid checking user secrets in to source control.

Marcin Zabłocki shows how he got ASP.NET Core debugging working on Ubuntu 16.04.

David Pine shows how to upgrade tools and application code from ASP.NET Core RC1 to RC2.

Muhammad Rehan Saeed presents a nice comparison between Azure Active Directory and IdentityServer.

Daria Grigoriu announces Azure App Service support for ASP.NET Core RC2, along with support for custom deployment scripts.

Tugberk Ugurlu describes the tooling changes he’s making as he updates his ASP.NET Core applications to RC2.

Here’s a deep dive into the ASP.NET Core CORS library, examinining implementation patterns and configuration.

Dave Paquette examines the recently added Distributed Cache Tag Helper, which allows you to store your ASP.NET Core cache outside of the ASP.NET Core host process.

Eric L. Anderson highlights some important differences in migrating from ASP.NET Core RC1 to RC2.

Pratap Lakshman announces MSTest Framework support for ASP.NET Core RC2.

Tony Sneed walks through how to use Entity Framework 6 in an ASP.NET Core application.

Julie Lerman documents the process of updating an ASP.NET Core / EF application to ASP.NET Core RC2.

Ben Cull overviews the basic EF Migration commands and provides a workaround to get migrations working for a Class Library project.

Jurgis Pasukonis walks through creating a new ASP.NET Core application on OS X, running it in Docker, and deploying to AWS container service.

Ben Foster explains how Kestrel URLs are configured in ASP.NET Core RC2.

Shayne Boyer shows how he called a WCF service from an ASP.NET Core application.

Simone Chiaretta shows how to set up debugging for .NET Core RC2 applications in Visual Studio Code.

Jon Smith shares some comprehensive templates for React applications in both ASP.NET Core and ASP.NET MVC 5.

Rick Strahl shows how to take advantage of strongly typed configuration settings in ASP.NET Core.

Sergio Sisternes walks through the process of deploying an ASP.NET Core application to Docker, along with some interesting “extra credit” steps once that’s running.

Hisham Bin Ateya shows how to optimize JavaScript and CSS files using a custom minifier tag helper.

Here’s a tutorial from Fiyaz Hasan covering anti-forgery in Angular / ASP.NET Core applications.

Khalid Abuhakmeh shares a fluent builder approach for conditional middleware configuration.

Hisham Bin Ateya shares a nice Bootstrap based language switcher tag helper.

Discussion

Scott and Damian took some time to reflect on some of the comments we have heard regarding the recent announcements and discussions for .NET Core. They started with the post about ‘Making it easier to port to .NET Core‘.

They heard the confusion about the migration and portability capabilities discussed in this post. Scott says that the .NET Core team really wants to have a great experience building for mobile devices with Xamarin and UWP and also a great experience when building applications for the web or a server. Sometimes there are conflicting designs that need to be resolved, such as the larger framework available for the development of mobile applications and the ASP.NET Core framework attempting to deliver a smaller server-focused version of the framework. The direction discussed in that blog post is not an attempt to take away from the server framework’s goal.

Damian asked about the concerns some folks had about the use of mscorlib and if it means that the software constructed on GitHub is no longer useful. Scott indicated that the work done on GitHub to refactor and make smaller assemblies is still very valid, and they are discussing the best way to bring compatibility with mscorlib targeted assemblies to ASP.NET Core. There are details around how applications will reference mscorlib, the .NET Core assembly, or even a Xamarin assembly at compile time. Its very early in the planning process, and the team is sharing their initial thoughts. The key goal is that ASP.NET Core should get better compatibility with the .NET frameworks that the majority of the world is currently using.

Scott went on to explain a few compatibility goals that the .NET teams have:

An existing Xamarin customer should be able to take their code to UWP projects. A UWP project should be able to take code and use it in a Xamarin project, and either of those codebases should be usable on a server. Unity should be similarly compatible with server, Xamarin, and UWP code.
We want to make packages the delivery vehicle for .NET without having to make a bunch of compiled binaries in separate folder in the package. Package contents should get much simpler for maintainers and consumers. They should be simpler and very compatible across Unity, Xamarin, UWP, Desktop, and Server.
Scott calls this ‘taking the development platform back’ and having the .NET team lead the direction of the framework. PCL was the smallest intersection of the capabilities of the various frameworks, and the .NET team wants to expand that definition to make it easier to re-use code. The example Scott references is that the UWP removed APIs from .NET because there were APIs in Windows that did the same thing. Scott wants to ensure that .NET developers can use these common APIs everywhere.

Damian went on to clarify the shared vision concept of the .NET frameworks. The shared capabilities are summarized in this graphic from Scott Hunter’s .NET Overview session at Build 2016:

The .NET Standard defines a common API surface for those shared features with a full implementation that is enabled for you when compiling for your specific target platform. There are things that could be brought back from mscorlib and NOT placed in .NET Standard, they could be placed only in those verticals appropriate for the target platform. This planning is still in the early stages, and the teams are working through these concepts.

Jon asked about timing: when are these changes going to occur, with a planned RTM in June, does this impact that? Damian clarified that this is a roadmap and a plan for features to add to .NET standard going forward. These plans should help to make .NET APIs common and available for polyglot developers who work on more than just server or just mobile. The APIs made available in .NET Core 1.0 RTM won’t change, they’ll grow and some will be contributed back to the .NET Standard. The plan has always been to add more APIs after 1.0 RTM, and this is the beginning of those discussions. Things like ADO.NET are in discussion as an API that could be made available after RTM.

The planned release in June will have the RTM of the ASP.NET Core framework with a preview 2 version of the tools, debuggers, and templates that support it. As more details emerge around future plans, the team will blog about it.

Scott indicated that sometimes the context of the standup videos, including the On .NET standup, gets lost. The team plans to blog more about their status, and writeups like this one will have more clarity about what the team is working on. Scott gave an example of the MSBuild changes that were discussed – the team finally got into a room and started discussing the direction last week. Something discussed as a direction doesn’t mean that its fully designed and engineers are writing code. Damian described that their process starts with a planned goal that has a number of directions for the team and those directions need to be planned out before engineers can write code to meet the original goals.

Scott indicated that the .NET vision and the goals being described in the open are just that: ideas. As part of the open approach from Microsoft, we want to discuss concepts as the development platform evolves.

With regards to the project.json to MSBuild change, the team ran into challenges in building a project.json model that supported MSBuild based libraries and capabilities while working with tools that only supported MSBuild. The team couldn’t justify spending two more years to build compatibility with every project type when they could go back to the incumbent and enhance it with the capabilities that we learnd from two years of development on project.json. As we realized that we wouldn’t deliver much more value in adding that compatibility compared to switching back to an MSBuild based model. We don’t plan to give up those features of project.json, and they will appear in MSBuild and csproj in the future.

Damian went on the clarify that the team wants to spend their time innovating framework features in the standard library and shared components so that all .NET developers can benefit. In this way, the vertical frameworks can focus on the innovations specific to their vertical.

If you have questions about these discussions or topics, please ask your questions below and someone from the team will answer you. This is a collaborative effort, and it is important to us that you get the information you need about these discussions. This also enables everyone to see and interact with the documentation about these changes.

Scott wants to ensure that the context of the major announcements happen on this blog and allow the standup videos to focus on discussing those features specific to the vertical. Scott is excited that the ASP.NET team is able to start talking about and working on web features.

A question came up about the difference between the RTM of the ASP.NET Core framework and the tooling being in a preview release. The runtime and framework has been in a real solid place, with a number of customers already running in production with the RC1 release and waiting for the RTM of ASP.NET Core. We were holding back the framework and runtime for the tooling, even though ASP.NET Core and .NET Core have been through their stress tests and security checks. We don’t want to keep you waiting for the resolution of some of these tooling changes that you may not need because the current ASP.NET Core meets your needs. If you need the interoperability of the planned MSBuild tool, you will need to wait for that to be completed.

The team is committed to eliminating any kind of migration effort between RTM and the VS15 tooling release. They plan to make opening a project is VS15 as easy as opening your VS2015 project and it will be converted to the new MSBuild model. The release of framework as an RTM with tooling still in preview is a bit weird, but not without precedent as the UWP tools went through a similar release schedule in 2015. The ASP.NET team knows that the tools are going to change, but the framework is not planned to change. They want to be able to enhance the tools without holding customers back any longer.

Scott also responded to some comments about “the .NET team got involved with ASP.NET Core and now things are in a strange place”. The ASP.NET and .NET efforts are being worked on by a single team that owns both products. Its one team, and in fact the folks that initiated the discussion to use MSBuild instead of project.json were responsible for ASP.NET. The team cares about all of the platforms: Unity, Desktop, Server, and Xamarin and wants everyone to succeed.

Tune in to dotNetConf the week of June 7-June 9 and we’ll be back the week after with another video.

↧

A Peek into .NET Open Source Contributions

June 10, 2016, 5:00 am

≫ Next: Notes from the ASP.NET Community Standup – June 14, 2016

≪ Previous: Notes from the ASP.NET Community Standup – June 2, 2016

During the dotNetConf virtual conference, Scott Hanselman shared a map and some charts that were constructed based on participation in Microsoft owned GitHub repositories. In the comments and social media since, we have heard your questions and we would like to provide some additional information about the data and some additional images.

Method

We wanted to answer the question: “Is Open Source .NET receiving contributions from the community?” Fortunately, all of the .NET source we wanted to measure was located in GitHub and accessible with the amazing Octokit.NET library. Yes, this is the same tool that Jasmine Greenway showed us during dotNetConf.

I wrote a set of simple data extraction methods that would copy data from GitHub to an Azure SQL database. Specifically, we extracted information about the aspnet/*, dotnet/*, xamarin/*, mono/mono, and Microsoft/vscode repositories. These extracts take a long time to run, having to analyze almost 200 repositories, so I turned the extraction process into a scheduled webjob and sent it off to Azure to run on a nightly basis.

Once the data started accumulating, I spent some time learning PowerBI. I had not used the tool before, and after spending some time learning about it and writing a few reports, I was hooked. Its so easy to attach to my Azure SQL database and start returning data.

Data Accuracy

Here’s the difficult part: to collect and identify user profile information, I used the GitHub API to query the publicly accessible user profile information for name, company, and location data. MANY individuals do not provide 100% accurate information in these fields, and that’s their choice. For those records that did have appropriate location information, I used the Bing Geocoding Helper with Bing Maps services to generate a latitude and longitude. Not everyone spells their locations in a way that Bing understands, but we took our best shot to get accurate data.

Results

I took those locations Bing returned and using the PowerBI map visualization plotted every .NET repository participant that doesn’t work for Microsoft. The results for June 9th 2016 are pretty amazing:

Where to from here?

We think there’s a lot of data about the .NET Community that would be amazing to share. Over the next few weeks, we’re going to investigate how we can share this information and make it interactive for you. Keep an eye on this blog for more about the .NET open source ecosystem. We thank everyone who is involved whether by opening issues, commenting on issues, writing code, writing tests, and writing documentation.

↧

Notes from the ASP.NET Community Standup – June 14, 2016

June 16, 2016, 7:50 am

≫ Next: Notes from the ASP.NET Community Standup – June 28th 2016

≪ Previous: A Peek into .NET Open Source Contributions

This week’s meeting is below:

This week, Damian, Scott, and Jon are back from delivering sessions at conferences and ready to update the community on the progress of ASP.NET Core. Your faithful transcriptionist was not back from some events, and Maher Jendoubi took the pen and wrote up the links and transcribed the questions from the meeting.

Check out Maher’s blog post for the complete list of links and questions answered by the team.

Thanks Maher!

Tune in next week for our final update before the scheduled release of ASP.NET Core.

↧

Notes from the ASP.NET Community Standup – June 28th 2016

July 1, 2016, 9:28 am

≫ Next: Notes from the ASP.NET Community Standup – July 5, 2016

≪ Previous: Notes from the ASP.NET Community Standup – June 14, 2016

This week’s meeting is below:

Asp.Net Core is released! Go to https://dot.net and get it now! Everyone’s going on vacation because its DONE! No.. Not really, the team is at it planning and getting ready for the next features in the web framework.

The surprise inclusion in this release is a browser-based REPL (Read-Eval-Print-Loop) for .NET at https://www.microsoft.com/net From here, there’s a great set of tutorials and in-browser development experience for .NET. We’re jazzed about this new way to present and teach .NET concepts. You can now get started learning .NET without installing Visual Studio or and SDKs. Or even get started learning .NET WHILE you wait for Visual Studio to install.

This week, instead of answering piles of questions about 1.0 RTM, Damian shared a live upgrade experience of the live.asp.net website that hosts the Community Standup. It was a painless process and we’ll review some of the highlights of the changes Damian applied to the application.

Damian showed us a block of comments that he added to the bottom of the page to show some information about the environment that the application is running in.

environmentInfo

Scott made a point that running small web sites in the cloud, like Azure Web Applications, don’t need x64 processing and can run very nicely in smaller x86 processes.

Damian showed us the staging environment for the live.asp.net site and how he can detect whether the Azure deployment (code named kudu) deployed his application and what the Git SHA hash for that deployment is. You can see this code on lines 37-82 of the DeploymentEnvironment class in live.asp.net. This SHA will match up with the SHA listed in the commits for the application on GitHub:

In order to protect the Dev version of the source that Damian had last modified, he created a new branch in his local source repository by executing the command:

git checkout -b rtm

This creates a new branch using a technique called “feature branches” where new features or experiments on your source code is performed in a local space where it is isolated from current working code.

Damian then walked through the installed for the .NET Tooling Preview 2, as he has not applied the latest patch to the machine he was demonstrating from. To push his code to use the Preview 2 version of the dotnet command-line tool, Damian updated the global.json file to point to the new version of the tool:

Next, he updated project.json to reference the 1.0.0 version of his packages and the tools that were updated get pointed to a Preview 2 version:

There was a slight name change on one of the classes used for Authentication, the OpenIdConnectResponseTypes was renamed to drop the S on the end:

Finally, Damian applied an update for the system reflection information that we showed earlier as an output to his page:

With that change, Damian was able to run the application using the ASP.NET Core RTM. A complete diff of the changes Damian made can be found on GitHub at: https://github.com/aspnet/live.asp.net/commit/b94a26ad42a7763caf54f70a79b0c83b192a72ef#diff-274660eb4b1b1d963a330b471e10f41c

Damian and Scott went through the exercise of deploying the application to a Azure Web App staging slot. The deployment took some time due to retrieving and loading all of the dependencies from NuGet, npm, and a non-optimized compilation process.

Looking Forward

Next week, we’ll talk about our early thoughts for the roadmap including SignalR. There is a SignalR 2.2.1 servicing release for ASP.NET and the team will be starting on “SignalR Core”. Scott pointed out new updates to Visual Studio Code that automatically adds the C# extension and debugger if you don’t have that installed and are working with C# files. Next time, Scott suggested that the team reviews how to install daily builds of the SDK if you’d like to run with the absolute latest version of the tools.

↧

Notes from the ASP.NET Community Standup – July 5, 2016

July 13, 2016, 9:23 am

≫ Next: Notes from the ASP.NET Community Standup – July 12, 2016

≪ Previous: Notes from the ASP.NET Community Standup – June 28th 2016

(Note from Jeff: My apologies for the delay on this one)

This week’s meeting is below:

Community Links

Channel 9 has the video from RedHat DevNation where Scott announced the RTM of ASP.NET Core

Rick Strahl has an in-depth exploration of ASP.NET Core features and a getting-started deep-dive

Stephen Cleary shared his findings when working with .NET and .NET Core versions

Andrew Lock wrote about how to configure URLs for Kestrel and IIS Express in ASP.NET Core

Filip wrote some code for the WebAPIContrib project that enables web pages to be built with razor and served easily

Paul shared his experience upgrading a project to .NET Core 1 RTM

Michael walks through porting a .NET framework library to be compatible with .NET Core

Tomas Janczuk updated his EdgeJS project that allows you to host .NET Core applications inside of a nodeJS project.

Ben Cull wrote about using Entity Framework with class library projects. Damian gave us a friendly reminder that tooling that supports this type of activity is in preview.

Jonathan Channon showed us how to port OWIN middleware to ASP.NET Core

Dominic Baier updated his security samples for the RTM of ASP.NET Core

Martin Woodward shared some code that demonstrates how to PInvoke on Linux with .NET Core.

Travis wrote about Autofac and the process to update for RTM

The SignalR team is looking for feedback on their next release, SignalR 2.2.1

Damien updated his samples for using Angular2 with IdentityServer 4

The ASP.NET Monsters chatted with Mads Kristensen about the bundler-minifier

Tianxiang shared a sample that demonstrates how to use webpack and vue

Matias wrote some code to bundle and minify content for ASP.NET Core

Smidge is another option for bundling and minifying, and it has been updated to support RTM

Maxime has some middleware that writes content to disk so that your ASP.NET Core site gets written to disk as static HTML

Katacoda released a course that teaches you how to deploy ASP.NET Core as a docker container

Maher has decompiled the http://dot.net site to show how the tutorials work that the Microsoft team wrote

Adaptive shareed a couple of links that demonstrate an open-sourced real-time trading platform built on ASP.NET Core. This is a more complex sample to walk through. http://weareadaptive.com/2016/06/30/reactive-trader-cloud-net-core-series-intro/

Speeding up your ASP.NET Core Deployment to Azure

Damian did a review of the ASP.NET Core deployment that he demonstrated last week and showed how to improve the deployment process. Last week, it took approximately 12 minutes to deploy the application, and this was considered a “worst case” deployment because it delivered brand new content to the web server. In subsequent deployments, only the changes would be deployed, but it was still taking six to seven minutes.

Damian showed how there are two drives that support an Azure Web Application – a slow drive and a fast drive. The slow drive contains the code that persists to Azure blob storage across site restarts, machine moves, and deployments. The fast drive is local to the machine that hosts the application and is much faster. He then took us to the Kudu tooling console for his web application that lives at the https://YOURWEBAPPNAME.scm.azurewebsites.net. From this menu, he navigated to the Debug console and was presented with a console in the browser that he could use to test various elements of the deployment process.

The repository folder on the ‘slow drive’ is where the Kudu process places a copy of the source code that it will compile and deploy to IIS on the ‘fast drive’. The build scripts that Kudu uses to execute and build your application are found at: https://github.com/projectkudu/KuduScript/tree/master/lib/templates Kudu writes a log file to the site / deployments / SHA / log.log complete with timestamps so that you can measure and monitor a deployment.

Damian showed his work-around for this by moving his compile process from the ‘fast drive’ and he showed us the steps in that process. He started by navigating to the Application Settings in the Azure Portal for his web application and setting the environment variable “SCM_REPOSITORY_PATH” to a location under the d:\local folder, in his case he set it to d:\local\repository This instructs Kudu to clone the source of your project to the ‘fast drive’ and do the compilation and build work with the fast drive. The problem with this is that this compile location will be lost if you restart the web application or the application stops because Azure will deploy a new copy of the application to a new host location. You can click the button in the Azure portal to sync your source code and then redeploy the application.

This is just a work-around as the teams are working on improving the experience.

Questions

Question: What are the plans for packaging content in NuGet packages?

— The NuGet package spec now supports a contentFiles element that you can use for content. Check the NuGet blog post ‘ContentFiles Demystified‘ for more details.

Question: Is there a way to reduce the significant volume of packages that are referenced and added indirectly to my project when I reference netcoreapp in project.json?

— The default project model is a ‘portable project’ which does require and carry all packages for the framework with it. This happens because you are referencing netcoreapp with type ‘platform’. This portable model prevents packages the packages from being downloaded and these binaries from being written to your bin folder.

Question: Is there a way to change Azure Web Apps from using the folder structure “sites/wwwroot/wwwroot”

— You can change the configuration in Application Settings on the Azure portal, but we haven’t tested what happens with that

Question: Any update on making the ASP.NET Core Module OSS or stand-alone?

— If you are on a server where you just want the module installed, you can use the windows server installer with some command-line additions. More information about configuring IIS can be found in the ASP.NET Docs Open sourcing this module is on the roadmap.

Question: Any update on native compilation?

— No update currently… it is still under investigation

Question: Will NuGet’s package store global package folder location be available for use in other project models?

— Damian thinks this might be coming as part of the project.json -> csproj update. You can use this model now with project.json in other project types, and Oren Novotny has instructions on his blog about configuring other projects.

Question: When can we expect to see performance improvements on compile times?

— Its scheduled as part of the MSBuild work, and that’s where the team is currently focused.

Question: Are there any plans to bring in-memory compilation back?

— The features we demonstrated previously are still functioning, with compilations written to disk as files are changed, and in-memory compilation isn’t required to achieve the “change cs file and refresh the browser” feature. It is not as fast as it used to be, and the razor compilation is in-memory.

Question: Does the MSBuild process have a simple and straightforward way to publish packages from a class library?

— We expect the current features to still be available after the migration, we’re not entirely sure what shape that will take. More details will be shared as they are available.

↧

Notes from the ASP.NET Community Standup – July 12, 2016

July 13, 2016, 2:38 pm

≫ Next: Notes from the ASP.NET Community Standup – July 19, 2016

≪ Previous: Notes from the ASP.NET Community Standup – July 5, 2016

This week’s meeting is below:

This week, Scott is coming to us from the DotNetFringe conference in Portland where they evidently placed him in a dark room. Jon Galloway couldn’t make it to the standup this week, so there are no links to share. Today’s guest is Steve Sanderson, a member of the ASP.NET team for the last 6 months or so and is a founder of the KnockoutJS project. He’s been investigating using JavaScript frameworks to help improve ASP.NET Core. Steve’s project is called ASP.NET JavaScript services and can be found on GitHub.

The project gives you a good starting point for building web applications using various JavaScript frameworks. In particular, there are yeoman templates available for Angular 2 Knockout, React, and React with Redux. You can acquire the templates in a shell with the command :

npm install -g yo generator-aspnetcore-spa

This will allow you to generate a base-project with the command:

yo aspnetcore-spa

Steve showed us the Angular 2 version of this template, walked through the structure and configuration of the Angular code working with ASP.NET Core. The template’s TypeScript is built and managed with WebPack and Steve showed us the advantages of this toolset combined with ASP.NET Core. Additionally, Steve enabled hot-module reloading within the configuration of the ASP.NET Core application and his application was updated live in the browser as TypeScript code was saved within his application.

Steve then showed us a second configuration option that uses NodeJS to precompile the JavaScript application that is then served by the Kestrel server as static content and without the Angular framework. This prerender configuration is enabled with an asp-prerender-module tag helper attribute, which Steve tells us is enabled by default in his project template.

Then Steve showed us the ReactJS enabled project template that comes with the Yeoman generator we installed above. The template outputs the same demo functionality and user-interface, except it was written with ReactJS and TypeScript. As a bonus feature to this sample, and a feature of React, this sample can persist its page state across browser state. This enables a great JavaScript development experience where you can edit content directly in the developer tools panel of the browser and the content panel will update appropriately.

Finally, Steve showed us the React-Redux template that was installed and how you can use the redux browser plugin to make debugging much easier with snapshots of your client-side application state made available in your browser.

Summary

Please download the JavaScript services and follow the instructions from the GitHub repository and let us know what you think. If you like this project, star it on GitHub and write about it on your own blog. Post your questions as issues in that GitHub repository and we’ll review them to determine how we should proceed with this work. Steve also has a great post introducing the project on his blog that you should check out. We would love to hear your thoughts about this approach in the space below, and we’ll be sure that Steve and his team see your comments.

↧