Posted on Leave a comment

Workaround for Bower Version Deprecation

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.

Configure External Web Tools Path
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 (justcla) Profile Pic 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

Posted on Leave a comment

New Cocos Creator Tutorial Series

A brand new tutorial series just went live on devga.me (to join the existing Armory 3D series), the Cocos Creator Crash Course.

Cocos Creator Crash Course - Devga.me Tutorial Series

The series currently consists of the following tutorial parts:

Cocos Creator Tutorial Series homepage

There are a few more tutorial chapters in active development.  The existing content should already be enough to get you up and running using the Cocos Creator game engine!  There will also be at least one video tutorial covering basically everything covered by the text series.

GameDev News, Programming , , ,

Posted on Leave a comment

Changes to script debugging in Visual Studio 15.7

We’re always looking for ways to make developing with Visual Studio faster.  One of the tasks developers do many times a day is launching debugging sessions.  We identified that script debugging added about 1.5s per F5, but only about 15.5% of people actively debugged script using Visual Studio.

Based on the above, in Visual Studio 15.7 we made the decision to turn off script debugging by default to improve the overall experience for most users. If you want to turn the capability back on, you can do it from Tools | Options | Debugging | and check “Enable JavaScript debugging for ASP.NET (Chrome, Edge, and IE):

We also added the following dialog when you attempt to set a breakpoint with script debugging disabled:

When script debugging is ON, Visual Studio automatically stops debugging when the browser window is closed. It will also close the browser window if you stop debugging in Visual Studio. We added the same capability to Visual Studio when script debugging is OFF under Tools | Options | Project and Solutions | Web Projects:

With this option enabled:

  • Visual Studio will open a new browser window when debugging starts
  • Visual Studio will stop debugging when the browser window is closed

The following matrix shows you all the available options and the expected behavior for each combination:

Enable JavaScript debugging for ASP.NET (Chrome, Edge and IE) Stop debugger when browser window is closed What happens when you start debugging What happens when you stop debugging What happens when you close the browser window
TRUE TRUE New browser window always pops up New browser window always goes away, with all open tabs Debugging stops
TRUE FALSE New browser window always pops up New browser window always goes away, with all open tabs Debugging stops
FALSE TRUE New browser window always pops up New browser window always goes away, with all open tabs Debugging stops
FALSE FALSE Opens new tab if browser window already exists Browser tab/window stays open Debugging continues

If you want Visual Studio to return to its default pre-15.7 behavior, all you have to do is enable script debugging in Tools | Options | Debugging | and check “Enable JavaScript debugging for ASP.NET (Chrome, Edge, and IE). If you notice any unexpected behavior with these options please use report a problem in Visual Studio to let us know. If you have any feedback or suggestions regarding this change please let us know on uservoice or simply post a reply to this post.

Posted on Leave a comment

Armory Game Engine Tutorial Series

If you’ve recently been to the GameFromScratch tutorial series page recently you may have noticed the addition of a new Armory game engine tutorial series.  It’s not actually hosted on GameFromScratch, instead it’s on our newly launched sister site (watch out, the paints still wet!) DevGa.me.  Don’t worry though, nothings changed, it’s just a newer, cleaner, ArmoryDevGame900x600mobile friendly home for tutorial series, I’ll explain more about this later.  For now, just be aware there is a new text and video based tutorial series on the Armory game engine under development!

Armory (or Armory3D) is a newly free open source cross platform game engine that runs inside and tightly integrates with the Blender application.  If you are interested in learning more about Armory and why I’m so excited about it, be sure to check out Introduction to Armory video.  The series is still quite young but already there is a fair bit to get you started.  Right now the series consists of:

The entire series homepage is available here.

Additionally the video series has begun, lagging slightly behind the text series.  So far videos consist of:

There is a (very small for now…) playlist available here.

DevGa.me is not a blog format and does not have any news, it’s just home to tutorials.  I will however announce new tutorials here on GameFromScratch, so stay tuned!  If you want to discuss the new series, there is a conversation over on the Armory discussion forums or leave a comment below or on YouTube.

Programming, Art ,

Posted on Leave a comment

Blazor 0.4.0 experimental release now available

Blazor 0.4.0 is now available! This release includes important bug fixes and several new feature enhancements.

New features in Blazor 0.4.0 (details below):

  • Add event payloads for common event types
  • Use camelCase for JSON handling
  • Automatic import of core Blazor namespaces in Razor
  • Send and receive binary HTTP content using HttpClient
  • Templates run on IIS Express by default with autobuild enabled
  • Bind to numeric types
  • JavaScript interop improvements

A full list of the changes in this release can be found in the Blazor 0.4.0 release notes.

Get Blazor 0.4.0

To get setup with Blazor 0.4.0:

  1. Install the .NET Core 2.1 SDK (2.1.300 or later).
  2. Install Visual Studio 2017 (15.7) with the ASP.NET and web development workload selected.
    • Note: The Blazor tooling isn’t currently compatible with the VS2017 preview channel (15.8). This will be addressed in a future Blazor release.
  3. Install the latest Blazor Language Services extension from the Visual Studio Marketplace.

To install the Blazor templates on the command-line:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates

You can find getting started instructions, docs, and tutorials for Blazor at https://blazor.net.

Upgrade an existing project to Blazor 0.4.0

To upgrade an existing Blazor project from 0.3.0 to 0.4.0:

  • Install all of the required bits listed above.
  • Update your Blazor package and .NET CLI tool references to 0.4.0.

Your upgraded Blazor project file should look like this:

<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>netstandard2.0</TargetFramework> <RunCommand>dotnet</RunCommand> <RunArguments>blazor serve</RunArguments> <LangVersion>7.3</LangVersion> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.Blazor.Browser" Version="0.4.0" /> <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.4.0" /> <DotNetCliToolReference Include="Microsoft.AspNetCore.Blazor.Cli" Version="0.4.0" /> </ItemGroup> </Project>

Event payloads for common event types

This release adds payloads for the following event types:

Event arguments Events
UIMouseEventArgs onmouseover, onmouseout, onmousemove, onmousedown, onmouseup, oncontextmenu
UIDragEventArgs ondrag, ondragend, ondragenter, ondragleave, ondragover, ondragstart, ondrop
UIPointerEventArgs gotpointercapture, lostpointercapture, pointercancel, pointerdown, pointerenter, pointerleave, pointermove, pointerout, pointerover, pointerup
UITouchEventArgs ontouchcancel, ontouchend, ontouchmove, ontouchstart, ontouchenter, ontouchleave
UIWheelEventArgs onwheel, onmousewheel
UIKeyboardEventArgs onkeydown, onkeyup
UIKeyboardEventArgs onkeydown, onkeyup, onkeypress
UIProgressEventArgs onloadstart, ontimeout, onabort, onload, onloadend, onprogress, onerror

Thank you to Gutemberg Ribeiro (galvesribeiro) for this contribution! If you haven’t checked out Gutemberg’s handy collection of Blazor extensions they are definitely worth a look.

Use camelCase for JSON handling

The Blazor JSON helpers and utilities now use camelCase by default. .NET objects serialized to JSON are serialized using camelCase for the member names. On deserialization a case-insensitive match is used. The casing of dictionary keys is preserved.

Automatic import of core for Blazor namespaces in Razor

Blazor now automatically imports the Microsoft.AspNetCore.Blazor and Microsoft.AspNetCore.Blazor.Components namespaces in Razor files, so you don’t need to add @using statements for them. One less thing for you to do!

Send and receive binary HTTP content using HttpClient

You can now use HttpClient to send and receive binary data from a Blazor app (previously you could only handle text content). Thank you Robin Sue (Suchiman) for this contribution!

Bind to numeric types

Binding now works with numeric types: long, float, double, decimal. Thanks again to Robin Sue (Suchiman) for this contribution!

Templates run on IIS Express by default with autobuild enabled

The Blazor project templates are now setup to run on IIS Express by default, while still preserving autobuild support.

JavaScript interop improvements

Call async JavaScript functions from .NET

With Blazor 0.4.0 you can now call and await registered JavaScript async functions like you would an async .NET method using the new RegisteredFunction.InvokeAsync method. For example, you can register an async JavaScript function so it can be invoked from your Blazor app like this:

Blazor.registerFunction('BlazorLib1.DelayedText', function (text) { // Wait 1 sec and then return the specified text return new Promise((resolve, reject) => { setTimeout(() => { resolve(text); }, 1000); });
});

You then invoke this async JavaScript function using InvokeAsync like this:

public static class ExampleJSInterop
{ public static Task<string> DelayedText(string text) { return RegisteredFunction.InvokeAsync<string>("BlazorLib1.DelayedText", text); }
}

Now you can await the async JavaScript function like you would any normal C# async method:

var text = await ExampleJSInterop.DelayedText("See ya in 1 sec!");

Call .NET methods from JavaScript

Blazor 0.4.0 makes it easy to call sync and async .NET methods from JavaScript. For example, you might call back into .NET when a JavaScript callback is triggered. While calling into .NET from JavaScript was possible with earlier Blazor releases the pattern was low-level and difficult to use. Blazor 0.4.0 provides simpler pattern with the new Blazor.invokeDotNetMethod and Blazor.invokeDotNetMethodAsync functions.

To invoke a .NET method from JavaScript the target .NET method must meet the following criteria:

  • Static
  • Non-generic
  • No overloads
  • Concrete JSON serializable parameter types

For example, let’s say you wanted to invoke the following .NET method when a timeout is triggered:

namespace Alerts
{ public class Timeout { public static void TimeoutCallback() { Console.WriteLine('Timeout triggered!'); } }
}

You can call this .NET method from JavaScript using Blazor.invokeDotNetMethod like this:

Blazor.invokeDotNetMethod({ type: { assembly: 'MyTimeoutAssembly', name: 'Alerts.Timeout' }, method: { name: 'TimeoutCallback' }
})

When invoking an async .NET method from JavaScript if the .NET method returns a task, then the JavaScript invokeDotNetMethodAsync function will return a Promise that completes with the task result (so JavaScript/TypeScript can also use await on it).

Summary

We hope you enjoy this latest preview of Blazor. Your feedback is especially important to us during this experimental phase for Blazor. If you run into issues or have questions while trying out Blazor please file issues on GitHub. You can also chat with us and the Blazor community on Gitter if you get stuck or to share how Blazor is working for you. After you’ve tried out Blazor for a while please also let us know what you think by taking our in-product survey. Just click the survey link shown on the app home page when running one of the Blazor project templates:

Blazor survey

Thanks for trying out Blazor!

Posted on Leave a comment

Use Dependency Injection In WebForms Application

Dependency Injection design pattern is widely used in modern applications.  It decouples objects to the extent that no client code needs to be changed simply because an object it depends changes to a different one.  It brings you a lot of benefits, like reduced dependency, more reusable code, more testable code, etc.  in the past, it was very difficult to use Dependency Injection in WebForms application before.  Starting from .NET 4.7.2, it is now easy for developers to use Dependency Injection in WebForms applications.  With the UnityAdapter, you can add it to your existing WebForms application in 4 simple steps.

How to enable Dependency Injection in your existing WebForms application

Suppose you have a movie website which lists most popular movies in history.  You use repository pattern to separate the logic that retrieves the data and maps it to the business entity.  Currently you are creating business logic object and repository object in default.aspx page.  The code looks like bellow.

Now simply follow 4 steps below, you will be able to adopt Dependency Injection to decouple the MovieManager from default.aspx page. The sample web application is on this Github repo.  And you can use tag to retrieve the code change in each step.

1. Retarget the project to .NET Framework 4.7.2. (Git Tag: step-1)

Open project property and change the targetFramework of the project to .NET Framework 4.7.2. You would also need to change targetFramework in httpRuntime section in web.config file as illustrated below.

2. Install AspNet.WebFormsDependencyInjection.Unity NuGet package. (Git Tag: step-2)

3. Register types in Global.asax. (Git Tag: step-3)

4. Refactor Default.aspx.cs. (Git Tag: step-4)

Areas that Dependency Injection can be used

There are many areas you can use Dependency Injection in WebForms applications now. Here is a complete list.

  • Pages and controls
    • WebForms page
    • User control
    • Custom control
  • IHttpHandler and IHttpHandlerFactory
  • IHttpModule
  • Providers
    • BuildProvider
    • ResourceProviderFactory
    • Health monitoring provider
    • Any ProviderBase based provider created by System.Web.Configuration.ProvidersHelper.InstantiateProvider. e.g. custom sessionstate provider

Summary

Using Microsoft.AspNet.WebFormsDependencyInjection.Unity NuGet package on .net framework 4.7.2, Dependency Injection can be easily added into your existing WebForms application. Please give it a try and let us know your feedback.

Posted on Leave a comment

A Pixel Perfect Camera in Unity

If you are a pixel artist, one of the most challenging tasks you have to deal with is handling multiple resolutions and aspect ratios that your game might run at.  Thankfully if you are using the newest (Unity 2018.2b3 or later) version of Unity there is now a new component that makes this job borderline trivial.

Announced in the following tweet:

image

You can download the component and a couple sample scenes here on Github, and you can read more about it here.

The 2D Pixel Perfect package contains the Pixel Perfect Camera component which ensures your pixel art remains crisp and clear at different resolutions, and stable in motion.

It is a single component that makes all the calculations needed to scale the viewport with resolution changes, removing the hassle from the user. The user can adjust the definition of the pixel art rendered within the camera viewport through the component settings, as well preview any changes immediately in Game view by using the Run in Edit Mode feature.

Using the camera is simple, once the package is installed, it’s simply added to a camera and configure:

image

Your game should now scale gracefully across resolutions and aspect ratios.  To see the Pixel Perfect Camera in action be sure to watch this video, also embedded below.

GameDev News, Art, Programming

Posted on Leave a comment

Blender Game Engine In Blender 2.8–Life After Death

Last month we reported that Blender Game Engine (BGE) was being removed entirely from the source code of Blender for the upcoming major 2.8 release.  Judging by the comments section this was certainly a polarizing decision, with replies basically falling into two camps.  On one side there was a lot of “good riddance to bad rubbish” type replies, while in the other camp it was mostly “I’m done with Blender if this happens”.  Clearly the decision impact enough people that something had to be done.  Well, that something was just announced on Twitter:

image

The linked article from the developer mailing list:

Hi all,

The Blender Foundation Development Fund has reserved a number of bigger donations (also on donator’s request) for game engine and interactive 3D related features.

Now 2.8 is getting shaped up, it was time to check on this topic. Yesterday afternoon I met with Benoit Bolsee and a couple of Code Quest participants, to discuss the future of Blender’s real-time 3D needs and “interaction mode”.

The outcome is that Benoit accepted a grant to work as designer and lead developer for one year on bringing back a good real-time interactive 3D system in Blender. He will do this part-time, in average 1.5 days per week, starting July 1st.

Obviously all work and further discussions will be done in public; using our regular channels (mailing lists, code.blender.org, developer.b.o, devtalk.b.o). Help from other Blender developers is very welcome. This will be further announced when Benoit starts.

To summarise, work will first be done in two areas;

– Implement a high quality real-time viewport with physics/event handling. This should result in a pleasant & usable environment to setup and bake simulations.

– Design and prototype a new nodal logic system.

Related to this work is also to enable good support (export or some kind of integration) for external game engines such as Godot, Armory, Blend4Web, Unreal, Unity, etc.

I especially invite the first three (open source) projects to connect with us to find ways to keep a high level of compatibility.

Work on typical GE features such as super-fast drawing (LOD, etc) are welcome too but should be part of the regular work on Blender’s viewport and our internal drawing engines. That way everyone benefits. Laters,

-Ton-

Blender Game Engine is not coming back, but a great deal of the functionality that was removed with it will be returning. Additionally Blender will be working directly to support Blender as a game development tool for existing game engines.

<font face=”Calibri”></font>

Art, GameDev News, Programming ,

Posted on Leave a comment

Troubleshooting ASP.NET Core Performance Problems

This is a guest post by Mike Rousos

I recently had an opportunity to help a developer with an ASP.NET Core app that was functionally correct but slow when under a heavy user load. We found a few different factors contributing to the app’s slowdown while investigating, but the majority of the issues were some variation of blocking threads that could have run in a non-blocking way. It was a good reminder for me just how crucial it is to use non-blocking patterns in multi-threaded scenarios like a web app.

Beware of Locks

One of the first problems we noticed (through CPU analysis with PerfView) was that a lot of time was spent in logging code paths. This was confirmed with ad hoc exploration of call stacks in the debugger which showed many threads blocked waiting to acquire a lock. It turns out some common logging code paths in the application were incorrectly flushing Application Insights telemetry. Flushing App Insights requires a global lock and should generally not be done manually during the course of an app’s execution. In this case, though, Application Insights was being flushed at least once per HTTP request and, under load, this became a large bottleneck!

You can see this sort of pattern in the images below from a small repro I made. In this sample, I have an ASP.NET Core 2.0 web API that enables common CRUD operations against an Azure SQL database with Entity Framework Core. Load testing the service running on my laptop (not the best test environment), requests were processed in an average of about 0.27 seconds. After adding a custom ILoggerProvider calling Console.WriteLine inside of a lock, though, the average response time rose to 1.85 seconds – a very noticeable difference for end users. Using PerfView and a debugger, we can see that a lot of time (66% of PerfView’s samples) is spent in the custom logging method and that a lot of worker threads are stuck there (delaying responses) while waiting for their turn with the lock.

Something's up with this logging call

Something’s up with this logging call

Threads waiting on lock acquisition

Threads waiting on lock acquisition

ASP.NET Core’s Console logger used to have some locking like this in versions 1.0 and 1.1, causing it to be slow in high-traffic scenarios, but these issues have been addressed in ASP.NET Core 2.0. It is still a best practice to be mindful of logging in production, though.

For very performance-sensitive scenarios, you can use LoggerMessage to optimize logging even further. LoggerMessage allows defining log messages ahead-of-time so that message templates don’t need to be parsed every time a particular message is logged. More details are available in ourdocumentation, but the basic pattern is that log messages are defined as strongly-typed delegates:

// This delegate logs a particular predefined message
private static readonly Action<ILogger, int, Exception> _retrievedWidgets = LoggerMessage.Define<int>( LogLevel.Information, new EventId(1, nameof(RetrievedWidgets)), "Retrieved {Count} widgets"); // A helper extension method to make it easy to call the 
// LoggerMessage-produced delegate from an ILogger
public static void RetrievedWidgets(this ILogger logger, int count) => _retrievedWidgets(logger, count, null);

Then, that delegate is invoked as needed for high-performance logging:

var widgets = await _dbContext.Widgets.AsNoTracking().ToListAsync();
_logger.RetrievedWidgets(widgets.Length);

Keep Asynchronous Calls Asynchronous

Another issue our investigation uncovered in the slow ASP.NET Core app was similar: calling Task.Wait() or Task.Result on asynchronous calls made from the app’s controllers instead of using await. By making controller actions async and awaiting these sorts of calls, the executing thread is freed to go serve other requests while waiting for the invoked task to complete.

I reproduced this issue in my sample application by replacing async calls in the action methods with synchronous alternatives. At first, this only caused a small slowdown (0.32 second average response instead of 0.27 seconds) because the async methods I was calling in the sample were all pretty quick. To simulate longer async tasks, I updated both the async and synchronous versions of my sample to have a Task.Delay(200) in each controller action (which, of course, I used await with when async and .Wait() with when synchronous). In the async case, average response time went from 0.27s to 0.46s which is more or less what we would expect if each request has an extra pause or 200ms. In the synchronous case, though, the average time went from 0.32 seconds to 1.47 seconds!

The charts below demonstrate where a lot of this slowdown comes from. The green lines in the charts represent requests served per second and the red lines represent user load. In the first chart (which was taken while running the async version of my sample), you can see that as users increase, more requests are being served. In the second chart (corresponding to theTask.Wait() case), on the other hand, there’s a strange pattern of requests per second remaining flat for several minutes after user load increases and only then increasing to keep up. This is because the existing pool of threads serving requests couldn’t keep up with more users (since they were all blocked on Task.Wait() calls) and throughput didn’t improve until more threads were created.

Threads Keeping Up

Asynchronous RPS compared to user load

 

Sync Thread Growth Lag

Synchronous RPS compared to user load

 

Attaching a debugger to both scenarios, I found that 75 managed threads were being used in the async test but 232 were in use in the synchronous test. Even though the synchronous test did eventually add enough threads to handle the incoming requests, calling Task.Result and Task.Wait can cause slowdowns when user load changes. Analyzers (like AsyncFixer) can help to find places where asynchronous alternatives can be used and there are EventSource events that can be used to find blocking calls at runtime, if needed.

Wrap-Up

There were some other perf issues in the application I helped investigate (server GC wasn’t enabled in ASP.NET Core 1.1 templates, for example, something that has been corrected in ASP.NET Core 2.0), but one common theme of the problems we found was around blocking threads unnecessarily. Whether it’s from lock contention or waiting on tasks to finish, it’s important to keep threads unblocked for good performance in ASP.NET Core apps.

If you’d like to dig into your own apps to look for perf trouble areas, check out the Channel9 PerfView tutorials for an overview of how PerfView can help uncover CPU and memory-related perf issues in .NET applications.

Posted on Leave a comment

Announcing ASP.NET Providers Connected Service Visual Studio Extension

Provider pattern was introduced in ASP.NET 2.0 and it gives the developers the flexibility of where to store the state of ASP.NET features (e.g. Session State, Membership, Output Cache etc.). In ASP.NET 4.6.2, we added async support for Session State Provider and Output Cache Provider.  These providers provide much better scalability, and enables the web application to adapt to the cloud environment.  Furthermore, , we also released SqlSessionStateProviderAsync, CosmosDBSessionStateProviderAsync, RedisSessionStateProvider and SQLAsyncOutputCacheProvider.  Through these providers the web applications can store the Session State in Azure resources like, SQL Azure, CosmosDB, and Redis Cache, and Output Cache in SQL Azure.  With these options, it may be not very straightforward to pick one and configure it right in the application.  Today we are releasing ASP.NET Providers Connected Service Visual Studio Extension to help you pick the right provider and configure it properly to work with Azure resources.  This extension will be your one-stop shop where you can install and configure all the ASP.NET providers that are Azure ready.

How to install the extension

The ASP.NET Providers Connected Service Extension can be installed on Visual Studio 2017. You can install it through Extensions and Updates in Visual Studio and type “ASP.NET Providers Connected Service” in the search box. Or you can download the extension from Visual Studio MarketPlace.

How to use the extension

To use the Extension, you need to make sure that your web application targets to .NET Framework 4.6.2 or higher.  You can open the extension through right clicking on the project, selecting Add and clicking on Connected Service. You will see all the Connected Services installed on your VS which apply to your project.

After clicking on Microsoft ASP.NET Providers extension. You will see the following wizard window, you can choose the provider you want to install and configure for your ASP.NET web application. Currently we have two sets of providers, Session State providers and Output Cache provider.

Select a provider and click on the Next button. You will see a list of providers that apply to your application, which connects with Azure resources. Currently we have SQL SessionState provider, CosmosDB SessionState provider, RedisCache Sessionstate provider and SQL OutputCache provider.

After the provider is chosen, the wizard window will lead you to select an Azure instance which will be used by the provider selected.  In order to fetch the Azure instances that apply to the selected provider, you will need to sign in with your account in Visual Studio.   Then Select an Azure instance and click on the Finish button, the extension will install the relevant Nuget packages and update the web.config file to connect the provider with that selected Azure instance.

Things to be aware of

  1. If the application is already configured with a provider and you want to install a same type of provider, you need to remove that provider first. E.g. your application is using SQL SessionState provider and you want to switch to CosmosDB SessionState provider. In this case, you need to remove the SessionState Provider settings in the web.config, then you can use ASP.NET Providers Connected Services to install and configure the CosmosDB SessionState provider.
  2. If you are installing Async SQL SessionState provider or Async SQL OutputCache provider, you need to replace the user name and password in the connection string in web.config added by ASP.NET Providers Connected Services. As you may have multiple accounts in your Azure SQL Database instance.

Summary

ASP.NET Providers Connected Services helps you install and configure ASP.NET providers for your web application to consume Azure services. Our goal of this Visual Studio extension is to make it easier and provide a central place to help you configure different providers for the ASP.NET web applications and connect your web applications with Azure. Please install the extension from Visual Studio Marketplace today and let us know your feedback.