HELP! - How to get Aurelia working in .NetCore MVC

[roddharris]

So I used Aurelia CLI 1.0.0-beta.?? (pre 13) to “generate” aurealia base within an MVC app following the instructions found on this site. (Basically, create the .NetCore project, go into the .proj directory and type au new --here. I used WebPack and Babel. While that got my project up and running, it only works on my local dev environment. When I publish my code to an Azure App Service, I start getting errors telling me that babel-polyfill can only be loaded once.

I upgraded to CLI 1.0.0-beta.13 and went through the same steps. Now, I can’t even run the project in my dev environment because I get a 404 on dist/app.bundle.js. I notice that in the dist folder, there is a runtime~app.bundle.js. However, if I update my Index.js file to load runtime~app.bundle.js, I get no errors – but nothing loads.

Has anyone been successful in getting a .NetCore MVC/aurelia app running in production?

[constructor]

You are not the only one to run into these issues. I will post some information for you.

To solve your immediate issues, look at this post

Aurelia CLI dotnet core 2.2 not updating src files

I agree with everything you said, in fact, I have said the same thing in past posts. This is why I created my own templates. The dotnet template has ‘Home/Index’ view that contains the <div aurelia-app="main">. This also has a scripts section that looks like this (aurelia-cli v1.0.0-beta.13): @{ ViewData["Title"] = "Home Page"; } <div aurelia-app="main">Loading...</div> @section scripts { <environment names="Production"> <script type="text/javascript" asp-src-include="~/dist/common.*.…

If you use Visual Studio 2017 you may wish to look at this post:

Aurelia CLI - Visual Studio 2017/2019 Tools

Updated 30/03/19 : Click image to watch video. Update includes: A new Visual Studio Aurelia template with no CLI dependency Very lightweight and fast A few miscellaneous bug fixes Check the video to see how quickly a basic project can be set up and published. I find using it a breeze and it seems to have great performance. [IMAGE ALT TEXT HERE] You can test the extension by on using Visual Studio 2017 and 2019 by getting it from here: Download Extension now It is not intended for live us…

These .NET templates have had issues for a while and I have been looking into this for the past few days. I will update the last thread very soon with some more information.

[roddharris]

Well, I got it working and I’d love to tell you how – but I’m not sure exactly what happened.

One thing that was definitely causing problems is that I had not checked the Remove additional files at destination in my Publish Settings. I think this was causing chunks to be renamed and conflict because old chunks were being loaded.

After correcting the above issue, I stopped getting the babel-polyfill error and started getting a 404 on the chunk files. I found I had to edit my webpack.config.js file and change the output.publicPath value from baseUrl to baseUrl+"dist/".

Again, my webpack.config.js file was created using a much earlier version of the Aurelia CLI. I may be wrong, but it appears the newer versions of the CLI want you to run au run on your project dir to launch the app whereas the older version allowed me to simply run IIS Expres from within VS 2017 and it would launch my app. I needed this because it was a hybrid MVC/aurelia app (meaning that there were some MVC routes that handled some portions of the UI and there was a route that launched the aurelia portion of the UI).

I’m probably making this way more complex than it needs to be (mostly because I don’t really understand the cli and/or webpack very well), but I at least got my current project up and running!!

[roddharris]

I had run across that video in all my frantic searching and – not realizing that you were still working on those templates – began frantically trying to find the templates! Finally re-read the posts and realize those templates are still a work in progress.

Thanks so much for taking time to post. As you can see, I finally got things working. I’m REALLY looking forward to those templates though. Is there something I can subscribe to that will notify me when they’re complete!

[constructor]

If you (or anyone else for that matter) would like access to these templates, simply keep an eye on the thread with the video concerning the templates.

I will send a message to everyone who ‘likes’ the video post when I next update.

[roddharris]

I can’t thank you enough! Definitely looking forward to those templates.

Just out of curiosity, have you found the newer versions of the Aurelia CLI to be more problematic with .NETCore than the older versions? Like I said above, when I used the old version of the CLI (and hence got the older version of webpack.config.js), I followed the instructions and launched IIS Express and voila, the site came up.

Now that I’ve upgraded to CLI version 1.0.0-beta.13, I do the exact same steps launch IIS Express and get a 404 trying to load app.bundle.js.

(What’s sad is, I forgot to take note of what version I had before I upgraded so now I don’t know how to get back to that CLI version that was working for me)

[constructor]

It is not Aurelia that is the problem, it is the templates. The script references seem to be incorrect.

Try this:

au new --here

Open the \Views\Home\Index.cshtml and change the ‘Development’ scripts to this:

<environment names="Development">
      <script type="text/javascript" asp-src-include="~/dist/*.bundle.js" asp-append-version="true"></script>
      <script type="text/javascript" asp-src-include="~/dist/*.chunk.js" asp-append-version="true"></script>
</environment>

Now:

dotnet run

Open: https://localhost:5001/

Now it works.

It should just work out of the box.

[brandonseydel]

The publish settings as stated will still be a problem unless they are turned on to remove the previous bundles. The application will load double bundles since when exporting they will be differently named. Something to keep in mind for the template as publish settings should be included for “Publish to Folder” option.

[constructor]

The same principle works when building for production. The output folder is cleared before each build. To reference the correct files the globbing needs to change:

<environment names="Production">
  <script type="text/javascript" asp-src-include="~/dist/*.bundle.js" asp-append-version="true"></script>
  <script type="text/javascript" asp-src-include="~/dist/*.chunk.js" asp-append-version="true"></script>
</environment>

Then:

au build --env prod
dotnet build -c {your-production-profile}
dotnet run --launch-profile {your-production-profile}

Open: https://localhost:5001/

The production build should be there.

Can you explain the ‘double bundles’ so I can check that?

I do agree that the ‘Publish’ procedure needs to work nicely.

[brandonseydel]

Lets also put a request in to the CLI to specify the aspnetcore version. It is literally as easy as changing the proj file and lets remove global.json. Do we really care what version of dotnet the tools run under?

[brandonseydel]

Also - We need to have these templates as “packed” and “unpacked”
Packed will objuscate away all of the aurelia/webpack stuff away. au unpack will take that information and explode it out. That way the directory is bare bones and just works. Expert users (enterprise level) can then explode the files to gain more control.

See below as project directory

If one were to run au unpack then the directory would go back to original state.

[brandonseydel]

Default publish

Results in

Which causes an issue when publishing out with default settings.

This should be addressed in the CLI as well. If we can get the CLI in tip top shape then we should be able to utilize it for generating the files for the selected template. This will reduce duplicate work across different IDES.

[constructor]

@brandonseydel

Lets also put a request in to the CLI to specify the aspnetcore version. It is literally as easy as changing the proj file and lets remove global.json. Do we really care what version of dotnet the tools run under?

The Aurelia CLI should not really care who is using it?

@brandonseydel

We need to have these templates as “packed” and “unpacked”
Packed will objuscate away all of the aurelia/webpack stuff away. au unpack will take that information and explode it out.

I can’t visualise what you mean by this.

When I begin a project all I want to do is “File > New Project”. This seems like the most natural thing to do, plus, the templates can be created a lot easier directly rather than conditionally in code.

I agree that the publish step should be working well, but it is also at the other end of the project life-cycle, whereas templates are about getting up and running easily (and without errors), saving time and getting to the fun part as quickly as possible. The chances are that the developer would implement their own deployment strategy along the way.

@brandonseydel

If we can get the CLI in tip top shape then we should be able to utilize it for generating the files for the selected template. This will reduce duplicate work across different IDES.

How long would it take you to add a new template, generated entirely in code, to the CLI?

Why generate a template for a specific IDE from within a separate tool, when a developer could just simply go ‘File > New Project’?

I do not see any duplicate work, only the addition of an alternative way to get started.

[brandonseydel]

1 - The aurelia CLI sets by default aspnetcore2.x without even scanning for installed versions or allowing a selection of installed versions. This is bad. I don’t even have 2.x any longer. I spin up a new app and its broke right off the bat.
2 - You need to visualize the average user in the fact that they have no idea what 90% of all the bundling and loading is doing and really don’t care to. Why would we include that into their solution? Take a look at create-react-app for what I am talking about.
3 - It isn’t a template per IDE. We would let the CLI do the work rather than hard coding releases for templates will make it work for VS or VS CODE. We will make a “dumb” template in VS that will invoke all the commands from the CLI. This generation should not be any less or more time than embedding in the template itself as it will just be living on the CLI on disk rather than on the template. I think the template would essentially be a VS GUI for a locally installed CLI next to the template.

[constructor]

1 - This is an issue with the CLI not the templates here (this thread). Have you asked for the reasoning behind how it currently works? If you don’t even have 2.x any longer, what are you using?

2 - Then create a template that works as you think it should and post the GitHub here. It would be great to see how it works!

3 - I have no problem with how the CLI works, except the long standing template issues I and others have faced. What I have posted is something that provides an alternative method of getting a .NET Core, Visual Studio specific experience (project templates, item templates and snippets) that uses the CLI.

As for the template itself, it is the default Visual Studio MVC template with Aurelia on top. Nothing more, nothing less.