Using Aurelia CLI with Visual Studio (again)


#1

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.


A simple way to create and manage Aurelia CLI templates
#2

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


#3

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.


#4

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


#5

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.


#6

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?


#7

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?


#8

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.


#9

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.


#10

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?


Using Aurelia CLI with Visual Studio - A solution
#11

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.


#12

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?


#13

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.


Aurelia CLI dotnet core 2.2 not updating src files
#14

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.