Subscribe: .NET slave
http://feeds.feedburner.com/netslave
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
add  app  core  essentials  extension  extensions  json  net core  net  studio  visual studio  visual  web essentials  web 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: .NET slave

Mads Kristensen



A blog about everything ASP.NET and ASP.NET Core as well as Visual Studio extensions such as Web Essentials.



 



Progressive Web Apps made easy with ASP.NET Core

Wed, 15 Nov 2017 12:47:20 PST

Earlier this week I wrote about some experiments I was doing with Service Workers in ASP.NET Core. This is an update to that. So, what is a Progressive Web App (PWA)? A Progressive Web App uses modern web capabilities to deliver an app-like user experience – Progressive Web Apps The benefits of PWAs are many. My personal favorites include: They are faster than regular websites They are more reliable They work offline They can be installed on the desktop or phone Most major browsers already support them (Safari and Edge coming soon) Any website or web application can add the capabilities that turns them into PWAs. The capabilities to add are: The website must be served over HTTPS Add a Web App Manifest (it’s a simple JSON file) Add a Service Worker (a JavaScript file) With ASP.NET Core we can automate a lot of this to make it easier and more integrated with the rest of the application. Getting started So, let’s get started turning our ASP.NET Core web application into a full fledged PWA by following a few easy steps. This will make your site work offline, be faster and installable by supporting browsers. Step 1 – install a NuGet package Install the NuGet package WebEssentials.AspNetCore.PWA into your ASP.NET Core project. Step 2 – add a manifest and icons Add a file called manifest.json in the wwwroot folder as well as 2 image icons. You can have as many image icons as you want as long as you have one in the size of 192x192 and one 512x512 pixels. Fill in the manifest.json file similar to this: { "name": "Awesome Application", "short_name": "Awesome", "description": "The most awesome application in the world", "icons": [ { "src": "/img/icon192x192.png", "sizes": "192x192" }, { "src": "/img/icon512x512.png", "sizes": "512x512" } ], "display": "standalone", "start_url": "/" } Step 3 – register a service Inside the ConfigureServices method in Startup.cs, add a call to services.AddProgressiveWebApp() like so: public void ConfigureServices(IServiceCollection services) { services.AddMvc(); services.AddProgressiveWebApp(); } Voila! The app is now a full blown PWA. To verify it works and your web app now behaves like a PWA in supported browsers, check out the verification step on the project readme. Also see how it is implemented in the Miniblog.Core source code which is a production web app. This very website (madskristensen.net) is also running it. Configuration There are plenty of ways to configure the behavior of the Web App Manifest as well as the service worker. Read the documentation for more info. I do want to call out that the NuGet package creates a strongly typed object (WebEssentials.AspNetCore.Pwa.WebManifest) out of the manifest.json file and makes it available in the dependency injection system. That way you can have a single source of truth for meta data properties such as application name, description and icon list. Next steps Read the full description of using the NuGet package where you’ll also find links to the various specifications and videos about PWAs.  Contribute If this is of interest to you and you’d like to contribute to the project on GitHub then you are more than welcome to do so. Open bugs, suggest features and send pull requests are all appreciated.[...]



Offline ASP.NET Core apps with service workers

Mon, 13 Nov 2017 11:04:02 PST

Update: The information in the blog post is outdated. Instead check out Progressive Web Apps made easy with ASP.NET Core.

What if you could make your ASP.NET Core web app faster to load and work offline without changing you code? You now can with the WebEssentials.AspNetCore.ServiceWorker NuGet package.

It registers a service worker that instructs the browsers how to cache resources and enable an offline experience. Most modern browsers support service workers with Edge and Safari currently implementing it.

Note, Service workers require HTTPS (except for localhost) to work.

Service workers are scripts that your browser runs in the background and act as a network proxy in the web browser to manage the web/HTTP requests programmatically

After installing the NuGet package, simply register the service in Startup.cs like so:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddServiceWorker();
}

That is all you have to do to enable service workers in your application. Here’s what it looks like with custom configuration:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddServiceWorker(new PwaOptions
    {
        Strategy = ServiceWorkerStrategy.CacheFirst,
CacheId = "v3", RoutesToPreCache = "foo.css, bar" }); }

Read more on the WebEssentials.AspNetCore.ServiceWorker GitHub repo about custom configuration and see how Miniblog.Core implemented it.

Progressive Web Apps

After implementing a service worker, you are now half way to turn your web app into a Progressive Web App (PWA). All you need to do is to add a JSON file called a Web App Manifest which is nothing but a few meta properties about your app such as name, description and list of icons. Here’s mine.




Miniblog.Core is a new blog engine built using ASP.NET Core 2.0

Thu, 26 Oct 2017 13:44:17 PDT

MiniBlog.Core is a new and powerful blog platform built on ASP.NET Core 2.0 and provides an excellent reading experience across devices. It achieves that through following the latest best practices for web development, including best-in-class performance, accessibility, readability, search engine optimization, social web integration using a mobile-first strategy. Check out the demo site and have a look at the source code. You can also get Miniblog.Core as a project template for Visual Studio by installing the ASP.NET Core Template Pack. This is the third blog engine I’ve built on top of ASP.NET. The first was BlogEngine.NET from 2007 which became the most popular blog engine on ASP.NET and might still be. It was created as a reaction to the blog engines of its time being way to complicated and hard to modify. I haven’t been active on that project for years, but there is still a team maintaining it. The second one was Miniblog in 2013 which explored HTML 5 and ASP.NET Web Pages to provide a clean code base with focus on customization and simplicity. Building Miniblog.Core I wanted to create a new blog engine based on ASP.NET Core that would take advantage of modern browsers to create the best possible experience for both visitors and authors. That meant that the blog had to load very fast, provide a great reading experience, look awesome on all types of devices and handle all the technical stuff like social media integration and search engine optimization automatically. Web fonts Selecting the right font is crucial to providing a good experience for the readers of the blog. Usually that means using a custom web font that is being loaded and used by CSS. The issue with custom web fonts is that the browser needs to download them and that can take a while on a slow mobile connection. Instead, I wanted to use fonts that are built in to the various browsers to provide the same high quality reading experience but without the extra file download. Here’s the CSS I use: body { font: 19px/1.6 "Open Sans", Ubuntu, "Nimbus Sans L", Avenir, AvenirNext, "Segoe UI", Helvetica, Arial, sans-serif; } The above font family ensures that at least one of the fonts is installed on any given browser/OS or device. Image optimization I’ve been using the Image Optimizer extension for Visual Studio for years to optimize the images in my web projects. That is great for images that I know of up front, but what about the ones uploaded by the users as part of the blog posts? Something was needed to optimize images on the production server as they were uploaded. As far as I know, there are no .NET Core libraries that can optimize images as well as the Image Optimizer extension can, so I created an Azure Webjob containing the exact same optimization algorithms as the extension and wrapped it in a NuGet package. It’s called Azure Image Optimizer and works by adding it to any ASP.NET project – no extra steps needed. When the ASP.NET app is published to Azure, the NuGet package will add a Webjob to the publish output that automatically starts up and monitors image files once it reaches Azure. It leaves no artifacts in your project and doesn’t require any code changes – simply add the NuGet package and deploy to Azure. Content delivery network (CDN) To make sure the blog could be optimized as much as possible, I decided to make it super easy to take advantage of CDNs to serve all the static files such as JavaScript, CSS and images. To do that, I use the WebEssentials.AspNetCore.CdnTagHelpers Nuget package that automatically CDNifies all static resource references by adding this to the appsettings.json: { "cdn": { "url": "https://myname.azureedge.net" } } Sass, bundling and minification I wanted to use Sass instead of plain old CSS so I needed a way to compile it. I could set up Gulp or WebPack to handle JavaScript and Sass transpilation, minification and bundling, but I decided to go with a [...]



Send ETag headers in ASP.NET Core

Thu, 17 Aug 2017 08:19:46 PDT

ASP.NET Core doesn’t add an ETag header automatically to HTTP responses from MVC action methods or Razor Pages. We have to implement that ourselves to provide the users with true Conditional GET support that honors the If-None-Match request header.

Wouldn’t it be nice if all we had to do was to register it using app.UseETagger() like this?

// Add "app.UseETagger();" to "Configure" method in Startup.cs
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseStaticFiles();

    // Add this after static files but before MVC in order
// to provide ETags to MVC Views and Razor Pages. app.UseETagger(); app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); }

We can if we use this little middleware class that handles the ETag and If-None-Match headers.




Long live Web Essentials

Thu, 02 Mar 2017 08:19:52 PST

In an episode of .NET Rocks from December 2016 I declared that Web Essentials would not be carried forward to Visual Studio 2017 and beyond. I’ve decided that was a bad idea, released a version for Visual Studio 2017 and here’s why.

Since Web Essentials was first released for Visual Studio 2010 it has grown and grown in both features and complexity. While providing a lot of functionality it became somewhat of a monolith to maintain. The size of the project was enormous and that probably was one of the main reasons only very few people helped out by sending pull requests. Another problem was that when a bug would crash Visual Studio in a feature you never used, you had to uninstall the entire extension instead of just the part that crashed. That was very frustrating for the affected users.

About a year and a half ago, I started on splitting all the features out into their own smaller extensions. The goal was to break up Web Essentials into smaller chunks that would be easier to maintain, have better test coverage, be very targeted and – most importantly – optional. That goal has been achieved and I’ve already seen the benefits in terms of more community involvement and higher quality. I get a lot more pull requests to the individual extensions than I ever did with Web Essentials and I’ve even made people contributors to several of the projects that they have shown a vested interest in. Success!

The process of splitting out Web Essentials into smaller extensions have taken more than 18 months and is now finally done.

Web Extension Pack –> Web Essentials

Having 20+ extensions instead of one presents a new challenge. How to make sure that Web Essentials users could find and easily install all those extensions. Enter Web Extension Pack 2015. It is a meta extension that does nothing but install all the new extensions. It was a great way to just point people to a single extension that would take care of adding all the features relevant to web developers.

Now that I’m done separating all of Web Essentials into smaller features, it felt like Web Extension Pack was pretty much the same thing Web Essentials used to be. Namely a single download that would add a bunch of helpful web development related features.

So I had a few options. Either keep the name “Web Extension Pack” and forever lose the good name and brand “Web Essentials”, or rename the Web Extension Pack extension to Web Essentials. I’ve chosen to rename in order to keep the brand, logo and generally positive associations people have with the name “Web Essentials”.

Web Essentials lives on, but with smaller optional pieces, higher quality, more focused functionality, more community involvement, simpler code bases, and a lot more fun for me personally to maintain.

Web Essentials 2017

I just updated Web Extension Pack 2017 with the renaming and branding change to make it Web Essentials 2017. The brand and logo is alive again and hopefully for many years to come.

Thanks to everyone who ever downloaded Web Essentials or any other of the smaller extensions, left comments, ratings, opened issues and sent pull requests. Keep the feedback coming.




Bundling, minification and client-side compilation

Mon, 08 Jun 2015 09:23:09 PDT

For the past couple of years, Web Essentials have been including features for bundling and minifying JS and CSS files as well as compiling LESS, Sass and CoffeeScript. As of Web Essentials 2015 that is no longer the case. However, I’ve gotten so many requests to bring these features back that I’ve created two new Visual Studio 2015 extensions to deal with it. And I need your help testing them before Visual Studio 2015 goes RTM.

Bundler & Minifier

This extension allows you to perform bundling and minification of JS, CSS and HTML files very easily and, in my mind, takes a better approach to how it’s done over the same feature in Web Essentials.

Download from VS Gallery Bundler & Minifier
Download nightly CI builds from vsixgallery.com
Source code on GitHub  
 

Web Compiler

Based on what I learned building compilers for Web Essentials, this extension improves on the stability and usability significantly. You can now very easily specify which LESS/Sass/CoffeeScript files to compile and with what settings for each file individually.

Read more and download Web Compiler
Download nightly CI builds from vsixgallery.com
Source code on GitHub 

Why new extensions?

In the past year or so, I’ve started separating out features from Web Essentials into smaller single-purpose extensions. I’ve done that for several reasons.

  1. It keeps the Web Essentials source code smaller and more maintainable
  2. Since it’s smaller, I hope to get more contributions from the community
  3. If one feature in Web Essentials cause a crash/hang, then the entire extension is broken
  4. Issues are much easier to deal with in smaller extensions
  5. By having smaller extensions, you can install just the ones you need

The code in Web Essentials for dealing with Bundling, minification and compiling was very error prone and almost impossible to maintain. For several months I wasn’t even able to compile Web Essentials itself due to a lot of weirdness in the node based compilers being used.

Help wanted

Given that these two extensions are brand new and the amount of requests for them has been so immense, it becomes really important that they both are working awesomely when Visual Studio 2015 goes RTM. So please help me test them out by installing them and reporting any issues to their GitHub issue tracker. If you want to contribute then you’re more than welcome to send pull requests with modifications and/or unit tests. If you want to add new features, all I ask is that you open an issue first so we can discuss it before sending the pull request.

These extensions are for a huge portion of Visual Studio web developers who don’t want to setup Grunt/Gulp to handle the client-side workflows, but instead have happily relied on Web Essentials in the past. These extensions are for you.




New handy Visual Studio extensions - part 2

Mon, 19 Jan 2015 12:22:34 PST

A few months ago I wrote about some small handy extensions I created for Visual Studio. This is part 2 with even more handy extensions. So here are some of the extensions I’ve worked on since then.

Open Command Line

Though I’m not a console-person, I do use both PowerShell and the regular command line quite a bit. Mostly I use the command line to run Grunt commands or with other commands that have to do with my Visual Studio projects.

The problem is that I always have to cd my way to the root of my projects before I start executing any commands.

(image)

With the Open Command Line extension I can now just hit Alt+Space  to open my console of choice already on the path of my project root. It supports any console including PowerShell, cmd, Bash etc.

Download Open Command Line on the VS Gallery

Open from Azure Websites

Sometimes when I build websites, I need to download the deployed content and run it locally. That’s a little cumbersome to do manually, so this extension helps make this super easy.

The extensions adds an Open from Azure Websites button that does it all automatically and opens the remote website as a project in Visual Studio.

(image)

Download Open from Azure Website on the VS Gallery 

Visual Studio Auto Updater

I love Visual Studio extensions and I use a lot of them every day. However, it can sometimes be annoying to keep them all up-to-date when new versions are released.

(image) The Visual Studio Auto Updater will automatically download and install updates to extensions in the background so you don’t ever have to do it manually again. It will only update the extensions that you have approved for auto updating.

Download Visual Studio Auto Updater on the VS Gallery

All of these extensions are of course open source and available on either my GitHub profile or on the LigerShark profile.




Grunt and Gulp Intellisense in Visual Studio 2013

Mon, 15 Dec 2014 17:03:58 PST

Update Jan 16, 2015 – The newly released Visual Studio 2015 CTP 5 also supports Grunt/Gulp Intellisense using the files available in this blog post. In fact, the Intellisense will be a lot better in CTP 5 due to the support for Object Literal Intellisense in the JavaScript Editor.

I’ve spent some time figuring out how to get Intellisense working for Grunt and Gulp in the JavaScript editor. Today, I hit a breakthrough that lights up Intellisense automatically. All it requires is that you perform the following two steps:

  1. Download the JavaScript Intellisense files (zip with two files)
  2. Copy them to C:\Program Files (x86)\Microsoft Visual Studio 12.0\JavaScript\References

If you’ve installed Visual Studio under a different path, then you’ll have to find the correct folder at that location instead.

This trick also works in Visual Studio 2015 Preview, but then the folder to copy the JavaScript files to is: C:\Program Files (x86)\Microsoft Visual Studio 14.0\JavaScript\References

Here’s what it looks like when editing GulpFile:

(image)

And here is GruntFile:

(image)

This is my first attempt, so please give it a try and let me know what you think. I want to try building this into Visual Studio 2015 so your feedback is super important.




Grunt and Gulp Intellisense in Web Essentials 2015

Sat, 13 Dec 2014 12:57:05 PST

Update: See this new blog post for how to apply the Intellisense to both Visual Studio 2013 and 2015

The latest release of Web Essentials 2015 provides Intellisense for GruntFile and GulpFile. For Gulp it just works out of the box, but for Grunt we have to add a little JSDoc comment to our file for Intellisense to light up.

For Grunt, just add this JSDoc comment on top of the module.export line:

/**
* @param {Grunt} grunt
*/
module.exports = function(grunt) {…

The JSDoc comment instructs the JavaScript Intellisense engine that the grunt parameter is of type Grunt which is specified by Web Essentials.

JSDoc comments are now natively supported in Visual Studio 2015

Here’s a video showing the feature for both Gulp and Grunt.

[youtube:ScXvuavqhzo]


I hope to be able to remove the requirement on the JSDoc comments, so that Intellisense will just work without you having to do anything.




Fall update 2014 - my year in review

Sun, 05 Oct 2014 14:08:53 PDT

Last October I wrote about my road to Visual Studio 2013 which was one big diary entry for an entire year in my professional life. This is such an incredible time to be working on the Visual Studio Web Tools Team and I’m so proud to work with some of the smartest people in the industry. This time last year, we were almost ready to ship Visual Studio 2013, so here’s what has happened since then. A few months before shipping Visual Studio 2013 we already started the work on Update 2. We decided not to be part of the first update to VS2013 because we had some rather large features that we knew wouldn’t be ready before Update 2. One of those features was the Sass editor because we had received a lot of feature requests for it. It was the most requested feature on the Web Essentials UserVoice page in fact. In Visual Studio 2012 Update 2 we released the LESS editor so we had plenty of experience with this type of CSS based language. Peter could reuse a lot of the code from the LESS editor (which he also implemented), so the iterations went pretty fast. Sass has a lot more features than LESS, so there was still a lot of new code and concepts to implement. The funny thing about both LESS and Sass is that they evolve very rapidly. It’s not like web standards from the W3C which can be years in the making. These two languages introduce new features and concepts many times a year, so it is a bigger challenge to keep the editors up-to-date. We’re still working on updating both implementations for VS14 in order to keep up with the changes and we will continue to do so going forward. We had one additional editor to implement for Update 2 and that was for JSON. Visual Studio never had a JSON editing experience before and we felt it was important to have one. Alex had been working on the support for auto-updating the _references file up until Christmas 2013, so the work on the JSON editor didn’t start until December 28. We were very ambitious with the JSON editor, because we wanted more than just syntax highlighting. We also wanted schema based Intellisense, validation, formatting and more. A full language service was needed. We broke it down into several pieces: Basic language service Syntax highlighting Formatting Syntax validation Brace completion/matching JSON Schema Intellisense Draft v3 and v4 support JSON Schema validation Enables more accurate Intellisense We knew we couldn’t do all of that for Update 2, so both Mike and Todd helped out with the JSON Schema support while Alex was implementing the language service and Anh was testing it all. We refer to the Update 2 JSON editor as version 1.0. In Update 3 we added better formatting and other important tweaks and in Update 4 we’re adding the validator. This will be version 2.0. I sent a pull request to the official JSON Schema website that added Visual Studio as the only editor that supports JSON Schema. To this day it’s still the only one. We’re not done yet and will continue to improve the editor in VS14 and beyond. Our team is now responsible for 7 separate editors. The highest number by any Visual Studio team. The editors are: CSS LESS Sass CoffeeScript Web Forms HTML JSON It’s quite the task to keep them all up-to-date with every release of Visual Studio and its quarterly updates. It’s sometimes a little overwhelming. To make the experience with JSON Schemas even better, I started working on a website for storing various JSON Schema files. It’s called SchemaStore.org and is completely open source. Web Essentials will automatically download the schema files stored on SchemaStore.org and bind them to known JSON files such as package.json, bower.json etc. In VS14 we’ll build this feature in and open it up for cust[...]