Support for webpack + asp.net core 2

[JeroenVinke]

I'm submitting a feature request

• Library Version: 0.31.0

Please tell us about your environment:

• Operating System: Windows 10

• Browser: all

• Language: all

Current behavior: When generating a new webpack+asp.net core setup and upgrading it to netcoreapp2.0 it fails to run (https://github.com/aurelia/cli/issues/700#issuecomment-323507637https://github.com/aurelia/cli/issues/700#issuecomment-323513471). I believe that netcoreapp2.0 is more strict in the way it expects the structure to be than netcoreapp1.1

Expected/desired behavior:

Currently asp.net core isn't using the server views (.cshtml files). They are generated but not used, instead it uses the index.html that's generated by webpack. We'd have to change this to get it working: https://github.com/aurelia/cli/issues/700#issuecomment-323507637

• What is the motivation / use case for changing the behavior? So it works with asp.net core 2

[gregoryagu]

I have also been trying to get webpack + aspnetcore 2.0 to work.

The only issue I have found is that the index.html that is generated by webpack has an incorrect path to the app..bundle.js and vendor..bundle.js.

This is what is generated:

<script type="text/javascript" src="/app.5cd7e50b38f3346de7b9.bundle.js"></script><script type="text/javascript" src="/vendor.5cd7e50b38f3346de7b9.bundle.js"></script></body>

This is what SHOULD be generated:

In other words, the "dist" is missing so it's showing a 404 error for those two files. If I manually move the files to the root (not under 'dist') then aurelia starts up as expected.

[JeroenVinke]

The weird thing is that the index.html file does get served from the dist. e.g. localhost:8080 serves dist/index.html. Yet the bundles don't get served, and they are in the same directory as index.html. In aspnet core 1.1 this worked without any issues, so i'm not sure what changed. Regardless, I'd like to improve this setup and it'll probably fix this issue as well

[jblackburn21]

I'd like to vote for this.

I'm using this same setup, and am try to use the index.cshtml rather than the index.html to load my aurelia app. If I remove the [hash] from the file name so that asp.net passes the hash through the query string, then webpack middleware continuously runs bundling.

As a work around, I changed the Index.cshtml to be a template and use HtmlWebpackPlugin to generate the version with the correct bundle names.

It is interesting that the asp.net core SpaTemplate for aurelia sets this up correctly, but I haven't been able to determine what the difference in configuration is.

[JeroenVinke]

https://github.com/aurelia/cli/pull/741

[millicandavid]

Hey guys. I'm just curious why anyone would want to run Aurelia in a .NET Core web site. I come from a .NET background and I don't see any advantage to it so I must be missing something. What is the use case? I do my API in .NET but as a separate hosted app. I really don't like the project structure that Visual Studio creates. I prefer just creating my solution folder, having a UI folder under it where I use the Aurelia CLI to create my project to my specifications, and then create my ASP.NET WebAPI project in and API project folder under the solution directory. Not saying this is the best way by any means. Just what I do and was wondering why so many people wanted to use Aurelia in an ASP.NET Core site. If there's an advantage I want to know about it.

[Alexander-Taran]

@millicandavid Assuming is the worst thing we can do as developers. Fact is we can't know for sure for anybody else but us.

Real advantage is with JavaScript services when middleware runs webpack-dev-server and you have F5 experience

Like out of the box... boom f5 And everything is runing.. That's how most developers in vs world like it.

And that's actually great to get things going when you don't know what the hell is going on here with all those node_modules, webpack.config etc..

Try picking some stack you don't know.. Phoenix on Elixir for example.. and try to get it going. It'll be some time till you get it running. Compare that to "project->new->F5"

To fiddle with that structure you have to have some understanding.

[millicandavid]

@Alexander-Taran Thanks for the reply. That makes sense. The ease of the operating environment of VS and F5. I just thought typing "au run" was pretty simple too. My issue with the ASP.NET route was I couldn't tell what I need to deploy to my app when staging for QA. It was clearer to me with the structure set up by the CLI. But I guess that answers my question of it just being a more familiar operating environment as that's what I am most used to as well. I was just worried that I was missing some cool feature(s) by not hosting my Aurelia app in ASP.NET.

[gordon-matt]

@millicandavid Well, I can't speak for others, but for me .NET and Aurelia make a perfect couple. I have my own framework full of useful stuff, including various HTML Helpers and localization, amongst other things. None of which I would be able to make use of in plain HTML.

EXAMPLE 1

EXAMPLE 2

Additionally, there's the whole .NET Framework, Entity Framework, etc for the backend.. and I just LOOOOVE OData... to get an idea of this, check out my .NET Core 2.0 with Aurelia skeleton and look at the demo page called, "People" which is a simple example of how nicely Aurelia + Kendo + OData work beautifully together and couple that with HTML Helpers, etc... and it's a real beauty. It would be wonderful if Aurelia could treat .NET Core as a first class citizen. Anyway, right now I am considering moving from a JSPM setup to an Aurelia CLI setup, but not really sure where to begin for .NET Core. If anyone here has a link to a "How-to" or just some advice, that would be great.

[millicandavid]

@gordon-matt that's another good point. To make use of existing framework code that you have built up in .NET.

The backend is a different story. I like to house my service layer in a separate project anyway as I consider it a more generic use. You might have other client apps or even other systems making use of your service layer. But Aurelia is a web client framework that seems to be focused on SPA development where server-side processing (for the client) is generally pretty light. With Progressive Web Apps you'd be hitting the hosting web server even less for your web client if you consider the servicing layer a separate entity.