Using Aurelia CLI with Visual Studio (again)

To keep this short, here is what I did.

  1. Create a new dot net core 2.2 MVC app.
  2. ‘au new --here’ with all the options in the correct place in my project (same directory as .csproj)
  3. implement all the instructions.txt

It will not run. I get:
GET https://localhost:44315/dist/vendor.css net::ERR_ABORTED 404
GET https://localhost:44315/dist/app.bundle.js net::ERR_ABORTED 404

Is this approach even supported by the CLI?

Every time I revisit Aurelia I have the same barriers, always around getting up-and-running.

1 Like

Every time I revisit Aurelia I have the same barriers, always around getting up-and-running.

This is an unfortunate thing with the .NET Core landscape having been completely broken and changed several times since its inception, and it has been hard to keep up.

Apart from that, stuff does work at the moment, but the documentation is still a bit scattered on certain topics and not always up-to-date. If you open a GH issue with links to which instructions you followed, and specify exactly which options you used, that would make it easier for us to manage and solve.

It seems there is a problem with the webpack config generated by the aurelia cli. (reminder to self and @huochunpeng - we really need to create automated tests that run all the combinations on CI and try to run the generated apps and warn us if anything is broken…!)

Here’s what I did to get a working ASP.NET Core app (not saying this is the only combo that works, but I like to start with the simplest possible thing and add stuff as I need it):
create a new directory, cd to it

au new --here
[Webpack]> 1
[HTTP/1.1]> 1
[ASP.NET Core]> 2
[TypeScript]> 2
[Default]> 1
[None]> 1
[None]> 1
[No]> 1
[Visual Studio Code]> 1
[Yes]> 1
[Yes, use NPM]> 2

Now, replace the optimization section in webpack.config.js with this:

optimization: {
    splitChunks: {
      chunks: "initial",
      cacheGroups: {
        default: false,
        vendors: false,
        aureliaBinding: {
          test: /[\\/]node_modules[\\/]aurelia-binding[\\/]/,
          name: "vendor.aurelia-binding",
          enforce: true,
          priority: 28
        },
        aureliaTemplating: {
          test: /[\\/]node_modules[\\/]aurelia-templating[\\/]/,
          name: "vendor.aurelia-templating",
          enforce: true,
          priority: 26
        },
        aurelia: {
          test: /[\\/]node_modules[\\/]aurelia-.*[\\/]/,
          name: "vendor.aurelia",
          enforce: true,
          priority: 20
        },
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: "vendor",
          enforce: true,
          priority: 10
        },
        common: {
          name: 'common',
          minChunks: 2,
          chunks: 'async',
          priority: 0,
          reuseExistingChunk: true,
          enforce: true
        }
      }
    }
  },

Again, I’m sure this is not the only thing that works and there’s likely just one small tweak that would be sufficient to get it working, but I’m not the CLI guy so I’m just giving you a working piece I worked on a few months ago.

Now you can run dotnet run and you should see the app on https://localhost:5001 up and running

4 Likes

I will try what you have recommended, but I see that you are running via dotnet run when I am using a Visual Studio workflow.

I what have tried is this:

  1. In the webpack.config I created the following entry in the plugins section:
new HtmlWebpackPlugin({
      template: '_Layout_App.cshtml.ejs',
      filename: '../../Views/Shared/_Layout_App.cshtml',
      metadata: {
        // available in index.ejs //
        title, server, baseUrl
      }
    }),
  1. Created the referenced _Layout_App.cshtml.ejs template based on the default layout file and adding a @RenderSection("css", required: false) to the head for the css to be placed correctly.
  2. Created a AppController and view (that uses the layout above) to have control over how the Aurelia app is displayed and to whom (via the [Authorize] attribute).

Now building and running via Visual Studio works without error.

Without going over old ground, would like to restate these thoughts.

Another approach, rather than having static versioned templates, could use ‘diffs’ on individual files rather than conditionally generating template files in the CLI internally. Having customised the CLI when looking into these issues last year, I could see the maintainability challenges clearly.

It would be great to be able to do this:

  1. Create a new Visual Studio MVC project with the latest templates.
  2. au new --here and choose the options
  3. Hit CTRL-F5 and watch it run, or manually create a controller and paste in some code to the view that points at the compiled aurelia app.

This experience all effects perception as stated here.

I still think Aurelia is great, it is just such a time waste when I literally have to research to get up and running every time.

1 Like

Or clone https://github.com/MaximBalaganskiy/AureliaDotnetTemplate and Ctrl+F5 :slight_smile:

2 Likes

Yes that is another way. I have created some templates that are available in the links I provided above. I was really addressing how the CLI works.

Ideally, a Visual Studio template should be able to be ‘layered’ with the Aurelia CLI.

1 Like

I will try what you have recommended, but I see that you are running via dotnet run when I am using a Visual Studio workflow.

As someone who has worked with, and sworn by, Visual Studio since version 2003 up to version 2017 (I even got the 2019 preview Enterprise installed now and gave that a good try) I can tell you that I find Visual Studio Code to be the superior (that is, more productive) tool for web develop nowadays.

There are still good reasons to open a .NET (core) project in Visual Studio: C# refactoring, code analysis, testing and architecture tooling, various code generations plugins, you name it.

But for a TypeScript web client project, nah. I stick to VS Code. And I know many who feel the same about this, which might be why a Visual Studio-compatible template is not really out in the front anymore.
With a .NET backend I just have the two running side-by-side, with the solution file open in Visual Studio (and the SPA files ignored), and the SPA project root opened in VS Code. I’m even starting to move away from that though, since C# debugging is getting pretty good in VS Code too.

Maybe I’m (we’re) wrong though. Are there still good reasons to use Visual Studio over VS Code for SPA development?

1 Like

If you wish to make a decision to not support a specific line of tooling or workflow then that is bold decision.

When using visual studio I can have a back-end docker service running, an Android app (Xamarin) and an MVC based control panel app in development. To ask the developer to consider switching their workflow to fit the tools seems a forceful, though absolutely valid point of view.

I am in no position to question the development choices of anyone, but I would like to learn and understand the reasoning for preferring the CLI’s chosen method of generating templates, internally, in code, imperatively, with all the obvious maintainability challenges this approach brings.

Is it fair to ask the developer to change their dev environment to fit the framework they wish to use? I mean, if Visual Studio is not supported then maybe state that this is the case?

1 Like

I completely agree with your point of view and would like to emphasize that we have never decided to not support Visual Studio, and we probably will not decide this either. In fact we fully embrace the .NET landscape and what comes with it.

I was just clarifying what I believe is the likely reason for the Visual Studio based template being sub-par compared to the rest. Aurelia is maintained by volunteers who use it in their day-to-day work, thus while a lot of features are in place on request by the community, due to lack of time/resources the features that are best maintained tend to be those that we ourselves need to use in the projects we work on (and of course those that the community are most vocal about). We haven’t heard a lot about Visual Studio usage.

Of course that still doesn’t mean these things need to lag behind. But the CLI is one of those things that is tricky to automatically test whether everything still works. A few problems may surface only when the community finds and reports them. We are definitely eliminating this problem in vNext, but for vCurrent we still have some way to go. I am currently working on a way to automatically test all combinations of what the CLI can generate. It will take a bit of time.

Other than that the main point of my argument was to lay a basis for asking the genuine question “what do you need Visual Studio for when developing an SPA?” and you gave a concrete, useful answer to that. In fact this is something we can keep in mind and probably a scenario we want to try and cover with tests as well.

1 Like

I should add to this we are playing with idea of generating project files fully programmatically, instead of based on templates that sit in the CLI as static resources. This and other forms of code generation will play a big role in vNext to add more options, capabilities and make things more adaptable to specific project needs. Similarly, I have a some ideas to utilize these concepts for (semi-)automatic migration of vCurrent to vNext using code generation.

Personally, my preferred approach to this whole problem would be to do it properly from scratch in vNext, and then add the appropriate plugins so that it can be used for vCurrent as well. From a user perspective the two versions of Aurelia won’t be that different anyway. In vNext there will mostly be fewer dependencies and less boilerplate.

Does that approach involve the CLI taking ownership of the templates?

When creating a project I use the Visual Studio project templates as they are updated periodically. This means that the templates change, yes, but not usually very radically from a structural perspective.

Would it not be possible to create a standard project in Visual Studio (or any other IDE) and then modify the files of that project template with a ‘diff’ for each file requiring modification, thus adding the Aurelia project to the solution generated by the IDE?

For reference: I have posted a stopgap solution here. It contains 2 git repos and some notes on what I did to get up and running, quickly, the way I wanted.

1 Like

Thanks for this example!

Does that approach involve the CLI taking ownership of the templates?

I wouldn’t say the CLI strictly speaking ever does this. It’s just a one-off emit some parameterized files and that’s essentially it.

Would it not be possible to create a standard project in Visual Studio (or any other IDE) and then modify the files of that project template with a ‘diff’ for each file requiring modification, thus adding the Aurelia project to the solution generated by the IDE?

Doing such a ‘diff’ is already very close to the previous approach we had for this and requires the CLI’s scaffolding logic to be tightly coupled to the broad structure of a Visual Studio template. This tight coupling is precisely why it’s broken right now, and pretty tedious to fix.

We definitely need some sort of layered approach to this with a base template that is not tightly coupled (but also does not work on its own), and a small pluggable layer on top of that with some template-specific glue code to make it work with particular versions of particular templates.

I don’t know about the diffing. Of course it would be ideal, but it’s also much more work to implement and especially maintain. If I’m not mistaken that means diffing the appsettings.json w/e to insert the appropriate SPA server dependencies, as well as looking for some Startup.cs, parsing it with Roslyn and modifying the syntax tree to insert the SPA bootstrapping logic. And a couple more things. Honestly I would love that, but I don’t see it happening in the near future. Or maybe you meant something else?

Doing such a ‘diff’ is already very close to the previous approach we had for this and requires the CLI’s scaffolding logic to be tightly coupled to the broad structure of a Visual Studio template. This tight coupling is precisely why it’s broken right now, and pretty tedious to fix.

The whole point of diff and patch is to do away with all that scaffolding logic. You would have, for each file needing modification, an initial state and a modified state and a patch that is generated from the two. Then you can re-use these to create various Aurelia CLI templates.

I don’t know about the diffing. Of course it would be ideal, but it’s also much more work to implement and especially maintain.

I actually believe that it would be far less work to maintain.

I would have each file that requires modification have it’s own patch file generated from the before and after modification states. A CLI template would effectively be a composition of these individual patch files represented in a json file and given its own id. Maintaining these would be trivial, as generating a patch would be done with an small app that compares to folders of files (one containing the ‘before modification’ state and the other containing files modified for Aurelia).

Maybe it would just be easier to create a dotnet global tools based CLI compatible tool that would do this, if it is not possible with the CLI. I may look at it if I get the time.

On the note about diff / patch, feathers-plus-cli uses a slightly different approach where custom codes are contained inside markers. Anything outside markers will be replaced when “regenerated” by a newer version of the CLI.

Hi Maxim,

I cloned the template. I then ran dotnet restore. I then tried to do au run but I keep getting an error:

No Aurelia project found.

I’ve tried running au run from the root directory as well as the ClientApp directory. What am I missing?

It’s a webpack, not cli project - so just use npm scripts. Mind you, it hasn’t been updated for quite some time.

Not sure how relevant this is here, but I wrote some comments in another post a while back what I usually do when setting up a new .NET5/Core WebApi project to be used in VS2019: Aspnet core 5 webpack proxy server - #12 by Souldrinker

1 Like

Looks interesting. I will read that post today when I can find some spare time. :slight_smile:

A while ago, my colleague and I started development on a new web-based application for company internal usage. My colleague started with the backend (an .NET Core Web API application) and I started with the frontend (a vanilla TypeScript SPA with as little dependencies as possible).

I got annoyed with implementing my own tedious boilerplate implementations for a client-side MVVM-architecture and a client-side router, so I took a look at Aurelia and after a few weeks I migrated my frontend solution to it.

The point that I am trying to make here is that it might be useful to completely split the backend and the frontend development. My colleague and I did it that way due to our project’s history, but I personally will use that same approach again for any new Aurelia application that I will create.

Is there actually a need for such a project template that combines an Aurelia frontend and a .NET Core backend? Is it worth the maintenance effort?

Well, I suppose that depends on the situation. In many cases, especially if the frontend and backend is developed by different persons/teams your point makes perfect sense and separation is probably good in many (most?) cases.

But for us old fashioned full stack devs (at least for me) it feels good to be able to (after doing an npm start from the command line) be able to just press F5 in the studio to start the application, have all code in the same solution, be able to set breakpoints in Visual Studio (both server side C# and client side TypeScript code), not having to worry about CORS, deploy the whole app together as one package etc.

2 Likes