Category: Uncategorized

Microsoft Library Manager (LibMan) is now available in the general release of Visual Studio 2017 as of v15.8. LibMan first previewed earlier this year, and now, after a much-anticipated wait, LibMan is available in the stable release of Visual Studio 2017 bundled as a default component in the ASP.NET and web development workload.

In the announcement about the preview, we showed off the LibMan manifest (libman.json), providers for filesystem and CDNJS, and the menu options for Restore, Clean and Enable Restore-on-Build. Included as part of the release in v15.8 we’ve also added:
– a new dialog for adding library files
– a new library provider (UnPkg)
– the LibMan CLI (cross-platform DotNet global tool)

What is LibMan?

LibMan is a tool that helps to find common client-side library files and add them to your web project. If you need to pull JavaScript or CSS files into your project from libraries like jQuery or bootstrap, you can use LibMan to search various global providers to find and download the files you need.

To learn more about LibMan, refer to the official Microsoft Docs: Client-side library acquisition in ASP.NET Core with LibMan.

What’s new?

New dialog for adding library files

We’ve added tooling inside Visual Studio to add library files to a web project. Inside a web project, you can right-click any folder (or the project root) and select Add–>Client-Side Library…
This will launch the Add Client-Side Library dialog, which provides a convenient interface for browsing the libraries and files available in various providers, as well as setting the target location for files in your project.

New Provider: UnPkg

Along with CDNJS and FileSystem, we’ve built an UnPkg provider. Based on the UnPkg.com website, which sits on top of the npm repo, the UnPkg provider opens access to many more libraries than just those referenced by the CDNJS catalogue.

LibMan CLI available on NuGet

Timed with the release of Visual Studio 2017 v15.8, the LibMan command line interface (CLI) has been developed as a global tool for the DotNet CLI and is now available on NuGet. Look for Microsoft.Web.LibraryManager.Cli

You can install the LibMan CLI with the following command:

> dotnet tool install -g Microsoft.Web.LibraryManager.Cli

The CLI is cross-platform, so you’ll be able to use it anywhere that .NET Core is supported (Windows, Mac, Linux). You can perform a variety of LibMan operations including install, update, and restore, plus local cache management.

To learn more about the LibMan CLI, see the blog post: LibMan CLI Release or refer to the official Microsoft Docs: Use the LibMan command-line interface (CLI) with ASP.NET Core

Related Links

Happy coding!

Justin Clareburt, Senior Program Manager, Visual Studio

Justin Clareburt is the Web Tools PM on the Visual Studio team. He has over 20 years of Software Engineering experience and brings to the team his expert knowledge of IDEs and a passion for creating the ultimate development experience.

Follow Justin on Twitter @justcla78

What is it?

We’re making a big investment in routing starting in 2.2 to make it interoperate more seamlessly with middleware. For 2.2 this will start with us making a few changes to the routing model, and adding some minor features. In 3.0 the plan is to introduce a model where routing and middleware operate together naturally. This post will focus on the 2.2 improvements, we’ll discuss 3.0 a bit further in the future.

So, without further ado, here are some changes coming to routing in 2.2.

How to use it?

The new routing features will be on by default for 2.2 applications using MVC. UseMvc and related methods with the 2.2 compatibility version will enable the new ‘Endpoint Routing’ feature set. Existing conventional routes (using MapRoute) or attribute routes will be mapped into the new system.

public void ConfigureServices(IServiceProvider services)
{
 ...
 
 services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

public void Configure(IApplicationBuilder app)
{
 ....
 
 app.UseMvc();
}

If you need to specifically revert the new routing features, this can be done by setting an option. We’ve tried to make the new endpoint routing system as backwards compatible as is feasible. Please log issues at https://github.com/aspnet/Routing if you encounter problems.

We don’t plan to provide an experience in 2.2 for using the new features without MVC – our focus for right now is to make sure we can successfully shift MVC applications to the new infrastructure.

Link Generator Service

We’re introducing a new singleton service that will support generating a URL. This new service can be used from middleware, and does not require an HttpContext. For right now the set of things you can link to is limited to MVC actions, but this will expand in 3.0.

public class MyMiddleware
{
 public MyMiddleware(RequestDelegate next, LinkGenerator linkGenerator) { ... }
 
 public async Task Invoke(HttpContext httpContext)
 {
 var url = _linkGenerator.GenerateLink(new { controller = "Store",
 action = "ListProducts" });
 
 httpContext.Response.ContentType = "text/plain";
 return httpContext.Response.WriteAsync($"Go to {url} to see some cool stuff.");
 }
}

This looks a lot like MVC’s link generation support (IUrlHelper) for now — but it’s usable anywhere in your application. We plan to expand the set of things that are possible during 2.2.

Performance Improvements

One of the biggest reasons for us to revisit routing in 2.2 is to improve the performance of routing and MVC’s action selection.

We still have more work to, but the results so far are promising:

This chart shows the trend of Requests per Second (RPS) of our MVC implementation of the TechEmpower plaintext benchmark. We’ve improved the RPS of this benchmark about 10% from 445kRPS to 515kRPS.

To test more involved scenarios, we’ve used the Swagger/OpenAPI files published by Azure and Github to build code-generated routing benchmarks. The Azure API benchmark has 5160 distinct HTTP endpoints, and the Github benchmark has 243. The new routing system is significantly faster at processing the route table of these real world APIs than anything we’ve had before. In particular MVC’s features that select actions such as matching on HTTP methods and [Consumes(...)] are significantly less costly.

Improvements to link generation behavior for attribute routing

We’re also using this opportunity to revisit some of the behaviors that users find confusing when using attribute routing. Razor Pages is based on MVC’s attribute routing infrastructure and so many new users have become familiar with these problems lately. Inside the team, we refer to this feature as ‘route value invalidation’.

Without getting into too many details, conventional routing always invalidates extra route values when linking to another action. Attribute routing didn’t have this behavior in the past. This can lead to mistakes when linking to another action that uses the same route parameter names. Now both forms of routing invalidate values when linking to another action.

A conceptual understanding

The new routing system is called ‘Endpoint Routing’ because it represents the route table as a set of Endpoints that can be selected by the the routing system. If you’ve ever thought about how attribute routing might work in MVC, the above description should not be surprising. The new part is that a bunch of concerns traditionally handled by MVC have been pushed down to a very low level of the routing system. Endpoint routing now processes HTTP methods, [Consumes(...)], versioning, and other policies that used to be part of MVC’s action selection process.

In contrast to this, the existing routing system models the application is a list of ‘Routes’ that need to be processed in order. What each route does is a black-box to the routing system – you have to run the route to see if it will match.

To make MVC’s conventional routing work, we flatten the list of actions multiplied by the number of routes into a list of endpoints. This flattening allows us to process all of MVC’s requirements very efficiently inside the routing system.

---

The list of endpoints gets compiled into a tree that’s easy for us to walk efficiently. This is similar to what attribute routing does today but using a different algorithm and much lower complexity. Since routing builds a graph based on the endpoints, this means that the complexity of the tree scales very directly with your usage of features. We’re confident that we can scale up this design nicely while retaining the pay-for-play characteristics.

New round-tripping route parameter syntax

We are introducing a new catch-all parameter syntax {**myparametername}. During link generation, the routing system will encode all the content in the value captured by this parameter except the forward slashes.
Note that the old parameter syntax {*myparametername} will continue to work as it did before. Examples:

• For a route defined using the old parameter syntax : /search/{*page},
  a call to Url.Action(new { category = "admin/products" }) would generate a link /search/admin%2Fproducts (notice that the forward slash is encoded)
• For a route defined using the new parameter syntax : /search/{**page},
  a call to Url.Action(new { category = "admin/products" }) would generate a link /search/admin/products

What is coming next?

Expect more refinement and polish on the LinkGenerator API in the next preview. We want to make sure that this new API will support a variety of scenarios for the foreseeable future.

How can you help?

There are a few areas where you can provide useful feedback during this preview. We’re interested in any thoughts you have of course, these are a few specific things we’d like opinions on. The best place to provide feedback is by opening issues at https://github.com/aspnet/Routing

What are you using IRouter for? The ‘Endpoint Routing’ system doesn’t support IRouter-based extensibility, including inheriting from Route. We want what you’re using IRouter for today so we can figure out how to accomplish those things in the future.

What are you using IActionConstraint for? ‘Endpoint Routing’ supports IActionConstraint-based extensibility from MVC, but we’re trying to find better ways to accomplish these tasks.

What are your ‘most wanted’ issues from Routing? We’ve revisited a bunch of old closed bugs and brought back a few for reconsideration. If you feel like there are missing details or bugs in routing that we should consider please let us know.

Caveats and notes

We’ve worked to make the new routing system backwards compatible where possible. If you run into issues we’d love for you to report them at https://github.com/aspnet/Routing.

DataTokens are not supported in 2.2.0-preview1. We plan to address this for the next preview.

By nature the new routing system does not support IRouter based extensibility.

Generating links inside MVC to conventionally routed actions that don’t yet exist will fail (resulting in the empty string). This is in contrast to the current MVC behavior where linking usually succeeds even if the action being linked hasn’t been defined yet.

We know that the performance of link generation will be bad in 2.2.0-preview1. We worked hard to get the API definitions in so that you could try it out, and ignored performance. Expect the performance of URL generation to improve significantly for the next preview.

Endpoint routing does not support WebApiCompatShim. You must use the 2.1 compatibility switch to continue using the compat shim.

The Command Line Interface (CLI) is now available for Microsoft Library Manager (LibMan) and can be downloaded via NuGet. Look for Microsoft.Web.LibraryManager.Cli
The LibMan CLI is cross-platform, so you’ll be able to use it anywhere that .NET Core is supported (Windows, Mac, Linux).

Install the LibMan CLI

To install LibMan, type:

> dotnet tool install --global Microsoft.Web.LibraryManager.Cli

Once the LibMan CLI is installed, you can start using LibMan from the root of your web project (or any folder).

Using LibMan from the Command Line

When using LibMan CLI, begin commands with “libman” then follow with the action you wish to invoke.
For example, to install all files from the latest version of jquery, type:

> libman install jquery

Follow the prompts to select the provider and destination. Type the values you want, or press [Enter] to accept the defaults.

The install operation creates a libman.json file in the current directory if one does not already exist, then adds the new library configuration. It then downloads the files and places them in the destination folder. See the example below.

To learn more about the LibMan CLI, refer to the LibMan CLI documentation on the Library Manager Wiki.

Happy coding!

Justin Clareburt, Senior Program Manager, Visual Studio

Justin Clareburt is the Web Tools PM on the Visual Studio team. He has over 20 years of Software Engineering experience and brings to the team his expert knowledge of IDEs and a passion for creating the ultimate development experience.

Follow Justin on Twitter @justcla78

This week we released Visual Studio 2017 version 15.8. Our 15.8 update brings the following improvements for web developers:

• Custom docker image tags during Publish
• Zip push deployment for Azure Functions
• Managing user secrets in ASP.NET Framework projects (targeting .NET 4.7.1 or higher)
• Enabling Application Insights as part of publishing to Azure App Service
• Optimizing build performance for solutions containing ASP.NET Framework projects
• Author and source information for ASP.NET Core templates

Custom docker image tags during Publish

You can now customize the “Image tag” for Docker containers when publishing them to a container registry. The value can either be automatically generated by Visual Studio every time you publish (the previous behavior), or it be manually changed if you need a consistent tag (e.g. “latest”):

Zip push deployment & run from zip for Azure Functions

Visual Studio now provides the option to deploy and run Azure Functions projects as zip files:

Run-From-Zip is a runtime feature that allows ‘mounting’ a zip file and running directly from it. Your App runs directly over the ‘mounted’ zip file, which completely takes over your wwwrootfolder (which becomes read-only).  Using run from Zip offers the following benefits:

• Atomicity: when your application is deployed as as single unit, and updated as a single unit meaning publishing an update will never leave your app in a partially updated state
• Faster deployment of large applications
• Improved cold start performance

Managing user secrets in ASP.NET Framework projects (targeting .NET 4.7.1 or higher)

A feature that ASP.NET Framework projects were missing compared to ASP.NET Core was support for storing application secrets (e.g. connection strings, API keys, etc.) in a file outside of source control unique to each user. Now, with .NET Framework 4.7.1 and Visual Studio 15.8 it’s as simple as right clicking on the project in Solution Explorer and selecting “Manage User Secrets”:

Visual Studio will take care of the rest including downloading the necessary NuGet packages, updating the web.config file, creating the secrets file on disk and finally opening it for you to edit:

Note: Only available for projects targeting .NET Framework 4.7.1 or higher, if you can’t see the menu item make sure you have the 4.7.1 targeting pack installed and that the project is actually targeting 4.7.1, you can change it from project properties:

Enabling Application Insights as part of publishing to Azure App Service

When publishing to Azure App Service, Visual Studio asks you to either create a new App Service or re-use an existing one. If you choose to create a new App Service to host your application, Visual Studio now offers you the ability to also provision and configure Application Insights:

All you need to do is pick the region you would like Application Insights to be provisioned in and Visual Studio will make sure it’s configured to pick up telemetry events and metrics from the new App Service. If you wish to add custom events and metrics follow this guide. Of course, you can always set the field to “None” and Visual Studio will not provision nor configure Application Insights on your behalf.

Optimizing build performance for solutions containing ASP.NET Framework projects

We added a new menu item under Build | ASP.NET Compilation | Optimize Build Performance for Solution:

This new menu item is applicable to solutions containing ASP.NET Framework projects only and is not applicable to ASP.NET Core projects. Its purpose is to update specific ASP.NET related NuGet packages referenced by the codebase.

When an ASP.NET Framework codebase is using out-of-date packages, the inner loop performance of Visual Studio is impacted. The motivation behind updating these packages is to restore optimal inner loop performance for a given solution.  You will only have to do this once per solution and you will not have to deal with this problem in the future since the new package is designed in a way that even when it gets out of date it doesn’t affect the inner loop performance in Visual Studio.

Author and source information for ASP.NET Core templates

The dialog for new ASP.NET Core projects now shows you the author and source for the selected template:

• If the template is coming from a .NET Core SDK installed on the machine, the dialog will now display the version of the SDK as the source
• If the template is coming from a VSIX (i.e. Visual Studio extension) installed on the machine, the dialog will now display the name of the VSIX as the source

Conclusion

If you’re interested in the many other great things that Visual Studio 2017 15.8 brings, check out our Visual Studio 15.8 post on the Visual Studio blog.

We hope that you’ll give 15.8 a try and let us know how it works for you. If you run into any issues please report them using Visual Studio, or let us know what you think below, or via Twitter.

In recent releases of Visual Studio 2017, there has been a great focus on improving the experience of working with Razor files (*.cshtml). The improvements were aimed at addressing the most pressing customer-facing issues and included changes from formatting and IntelliSense to general performance and reliability. Now that the fixes and enhancements have been publicly available for a few months, we hope you’ve been having a much-improved experience with the Razor editor.

Please let us know how we’re doing by taking a short, two-minute survey. Also, feel free to leave relevant feedback in the comments section below.

If you haven’t already downloaded the latest version, update your copy of Visual Studio 2017 through the Visual Studio Installer, or follow the links to download the installer from the Visual Studio website.

We know that despite our improvements, Razor editing isn’t perfect yet, so if you run into issues please file a report using the Visual Studio feedback tool. We review this feedback frequently and will continue to fix issues that are identified.

To launch the feedback tool, choose “Report a Problem…” under the Help->Send Feedback menu. When filing a report, please provide as much of your Razor file as you can share, with a description of what happened versus what you expected. (Sample code and screenshots are very helpful!)

Thanks for your interest in Web Development in Visual Studio.
Happy coding!

Justin Clareburt, Senior Program Manager, Visual Studio

Justin Clareburt is the Web Tools PM on the Visual Studio team. He has over 20 years of Software Engineering experience and brings to the team his expert knowledge of IDEs and a passion for creating the ultimate development experience.

Follow Justin on Twitter @justcla78

As of June 25, the version of Bower shipped with Visual Studio was deprecated, resulting in Bower operations failing when run in Visual Studio. If you use Bower, you will see an error something like:

EINVRES Request to https://bower.herokuapp.com/packages/bootstrap failed with 502

This will be fixed in Visual Studio 15.8. In the meantime, you can work around the issue by using a new version of Bower or by adding some configuration to each Bower project.

The Issue

Some time, ago Bower switched their primary registry feed but continued to support both. On June 25th, they turned off the older feed, which the copy in Visual Studio tries to use by default.

The Fix

There are two options to fix this issue:

1. Update the configuration for each Bower project to explicitly use the new registry: https://reigstry.bower.io
2. Manually install a newer version of Bower and configure Visual Studio to use it.

Workaround 1: Define the new registry entry in the project’s Bower config file (.bowerrc)

Add a .bowerrc file to the project (or modify the existing .bowerrc) with the following content:

{
 "registry": "https://registry.bower.io"
}

With the registry property defined in a .bowerrc file in the project root, Bower operations should run successfully on the older versions of Bower that shipped with Visual Studio 2015 and Visual Studio 2017.

Workaround 2: Configure Visual Studio to point to use a newer version of Bower

An alternative solution is to configure Visual Studio use to a newer version of Bower that you have installed as a global tool on your machine. (For instructions on how to install Bower, refer to the guidance on the Bower website.) If you have installed Bower via npm, then the path to the bower tools will be contained in the system $(PATH) variable. It might look something like this: C:\Users\[username]\AppData\Roaming\npm. If you make this path available to Visual Studio via the External Web Tools options page, then Visual Studio will be able to find and use the newer version.

To configure Visual Studio to use the globally installed Bower tools:

1. Inside Visual Studio, open Tools->Options.
2. Navigate to the External Web Tools options page (under Projects and Solutions->Web Package Management).
3. Select the “$(PATH)” item in the Locations of external tools list box.
4. Repeatedly press the up-arrow button in the top right corner of the Options dialog until the $(PATH) item is at the top of the list.
5. Press OK to confirm the change.

Ordered this way, when Visual Studio is searching for Bower tools, it will search your system path first and should find and use the version you installed, rather than the older version that ships with Visual Studio in the $(VSINSTALLDIR)\Web\External directory.

Note: This change affects path resolution for all external tools. So, if you have Grunt, Gulp, npm or any other external tools on the system path, those tools will be used in preference to any other versions that shipped with VS. If you only want to change the path for Bower, leave the system path where it is and add a new entry at the top of the list that points to the instance of Bower installed locally. It might look something like this: C:\Users\[username]\AppData\Roaming\npm\node_modules\bower\bin

We trust this will solve any issues related to the recent outage of the older bower registry. If you have any questions or comments, please leave them below.

Happy coding!

Justin Clareburt, Senior Program Manager, Visual Studio

Justin Clareburt is the Web Tools PM on the Visual Studio team. He has over 20 years of Software Engineering experience and brings to the team his expert knowledge of IDEs and a passion for creating the ultimate development experience.

Follow Justin on Twitter @justcla78