Tag Archives: npm

.Net Client Side Libraries

In this post, I introduced (to me) a new method of installing client side Javascript libraries for a .Net Web Application.

In this follow-up, I’m going to cover how this can be used in conjunction with npm in order to simply move the files into the correct location. Note that this is a new tool in Visual Studio, and you’ll need VS 15.8.0 or higher for it to work. Let’s start by creating an empty .Net Core Web App. Once you’ve done so, you’re app probably looks like this:

Now you’ll need to launch a bash or powershell console:

npm init
npm install jquery

Refresh your project and show all files:

As you can see, you now have a node_modules directory. The problem is that the files need to be under wwwroot. Obviously, you could copy it, but let’s try the client side manager:

In the resultant dialog, select File System; navigate to the JQuery directory and select the files that you want:

Now refresh the project again and let’s see what we have:

This actually translates to a JSON file; libman.json looks like this:

{
  "version": "1.0",
  "defaultProvider": "filesystem",
  "libraries": [
    {
      "library": "node_modules\\jquery\\dist\\",
      "destination": "wwwroot/lib/dist/",
      "files": [
        "jquery.min.js"
      ]
    }
  ]
}

Abusing the system

Okay – so that’s very nice; but now that we have a system that will copy files from wherever into wherever (the rule is that you have to go deeper in the files structure – so you couldn’t copy that file back again) then we, presumably, could use this for other things. For example, have you ever had a file (an image or something) that you need to include in your project:

Obviously, c:\tmp above could just as easily be \\shareddrive\images.

To be clear, I’m unsure whether this is abusing the system, or it was meant for this exact thing. It is possible that this type of usage may become unsupported in future (so you’ve been warned).

Installing Client Side Libraries in Asp.Net Core

As a relative newcomer to the web front-end, one thing that always surprised me was how many moving parts you need to get something running. This is probably true elsewhere (i.e. in back-end development, and desktop development) but we just do a better job of hiding it. In the past, people writing web-pages have always has an uneasy relationship with Microsoft. Maybe it started in the late nineties when, in order to win the battle of the browsers with Netscape, Microsoft started giving its product away. Since then IE became more and more bloated, as it had to support 10 years worth of old technology, and people have had to ensure it still worked on IE 6 and 7.

But now things are different, Microsoft is a rebranded company and nobody hates them anymore… and when you create a brand new Asp.Net Core 2.1 project, you can use npm to install client side packages, use them in your web page and it all just works – end of the post.

Except that hasn’t happened. In fact, the client side package management for the web seems (to me) to be in a bit of a mess – especially where Microsoft is concerned.

Create a brand new Asp.Net Core 2.1 MVC project from the template and it comes with jquery, supplied by bower; except Microsoft aren’t continuing support for bower anymore.

So, use NuGet to install your package?

Nope – not on .Net Core!

So, use npm – that’s still supported?

Yep – here’s the Asp.Net Signal R client side package installed using npm:

Okay, so it puts it in ‘node_modules’ – I can reference the library directly from there, right?

Nope – it needs to be in wwwroot\lib.

Errr – so I copy it across manually?

You can. Although that’s kind of the problem that package managers were invented to solve.

I can create a gulp task to take the files out of the downloaded directory and place them into the lib directory!

Yes – yes, you can. Although now you have a gulp task, and an npm restore, all so that you can include one or two files in your project. This all just seems too hard!

LibMan

Introducing LibMan. It isn’t a Package Manager; but it might just be the correct answer to the question: “Why the hell is this whole thing so difficult – I only want one file!”

Here is the context menu for the in the lib folder after v15.8 (this has been available in preview for a while):

That gives you the following dialog:

This is amazing, I can pick the library that I want, and where I want it to go! I can also select specific files that I want – this almost feels like a sensible way to manage client side packages. Click install and bang:

You can see what it’s done by either selecting “Manage Client Side Packages…” from the solution context menu:

Alternatively, you can just have a look at the libman.json file (they both do the same thing as of 15.8.7, which makes me wonder whether “Manage Client Side Packages…” will do something different one day – the ellipses kind of give it away).

And There’s More…

There’s a CLI for it (which seemed to balk a bit when I tried to install it via NuGet), and you can use this as a replacement for Gulp to copy files around, by just selecting “File System” as the source (although this sort of solves that problem further down the tree).

References

https://docs.microsoft.com/en-us/aspnet/core/client-side/bower?view=aspnetcore-2.1

https://blogs.msdn.microsoft.com/webdev/2018/08/22/libman-cli-released/

https://blogs.msdn.microsoft.com/webdev/2018/08/31/library-manager-release-in-15-8/

Forcing an NPM Restore

I’ve recently started looking into the Javascript library ReactJS. Having read a couple of tutorials and watched the start of a Pluralsight video, I did the usual and started creating a sample application. The ReactJS template in VS is definitely a good place to start; however, the first issue that I came across was with NPM.

Upon creating a new web application, I was faced with the following errors:

The reason being that, unlike NuGet, npm doesn’t seem to sort your dependencies out automatically. After playing around with it for a while, this is my advice to my future self on how to deal with such issues.

The best way for force npm to restore your packages seems to be to call

npm install

either from Powershell, or from the Package Manager Console inside VS.

Powershell

On running this, I found that, despite getting the error shown above, the packages were still restored; however, you can trash that file:

Following that, delete the node_modules directory and re-run, and there are no errors:

Package Manager Console

In Package Manager Console, ensure that you’re in the right directory (you’ll be in the solution directory by default, which is the wrong directory):

References

https://stackoverflow.com/questions/12866494/how-do-you-reinstall-an-apps-dependencies-using-npm

AutoRest

In the world of WCF and SOAP, if you want to consume a WCF service, you simply ask VS to add a service reference, direct it to the WSDL file, and it generates a client for you. Wouldn’t it be nice if you could do the same for a REST service!

It turns out that you can (although, admittedly, the process is not as seamless). The tool of choice for providing this WSDL emulation is called Swagger. This post isn’t about Swagger, and it assumes that you know your Swagger source. Azure has its own flavour of Swagger, called “Azure Swagger” (seriously). Consuming that is the main focus of this.

AutoRest

AutoRest is the client-side tool that allows you to automatically create proxy classes for your REST interactions, and is available via NuGet… but it doesn’t work at the time of writing this.

Instead, use Node Package Manager (NPM). First, install it, via this link.

Next, install AutoRest. Your friend here is the Package Manager Console:

npm install -g autorest

Update the version (this is, as I understand it, not strictly necassary, as it will install the latest version):

autorest --latest

Finally, check the version that is installed (okay, clearly this isn’t necessary at all, but I like to check that the computer and me both have a synchronised view of events as often as possible):

autorest --list-installed

Next, check where you are:

Then call AutoRest:

AutoRest -Input [SwaggerLocation] -Namespace [Namespace]

A note on Namespaces

It’s tempting to be dismissive of the namespace. Remember that, the namespace that you give will be assigned to classes and used by classes… so, if you were, for example, to give a namespace that matched the class name (so, for example, if you’re creating Recommendations, you’ll have a class called “Recommendations”) then you’ll find you’ll get thousands of strange errors that apparently make no sense. Think carefully about the namespace!

Where is the Swagger Location?

Obviously, the answer is, it depends… however; for Azure, most services have that readily available; let’s take Recommendations:

References

https://github.com/Azure/autorest

https://azure.microsoft.com/en-gb/resources/videos/inside-autorest-with-david-justice/

https://www.nuget.org/packages/autorest/

https://dzimchuk.net/generating-clients-for-your-apis-with-autorest/

https://github.com/Azure/autorest/blob/master/README.md#installing-autorest