What is the difference between "wwwroot/dist" and "ClientApp/dist" folders after running this command and how to use them correctly?
dotnet publish -c Release
The wwwroot/dist folder is basically an exposed folder that stores the compiled distributions of all pre-compiled javascript or scss code in the other parts of the project.
The ClientApp/dist folder stores all the compiled distributions of all the frontend framework classes/files within the ClientApp folder (i.e. AngularJS code transpiled docs).
.NET Core SPA apps usually route to the ClientApp/dist folder when performing Dependency injection on the SPA side of things.
Related
A developer created a web front-end and deployed on server. Unfortunately when the vue application was developed I did not receive the original vue files so all I have access to are the files deployed on the server.
I'm unsure how vue works and if deployment means that the web application is compiled. If this is the case, is it essential to have the original vue project to make changes ?
What disadvantages will I encounter without the project file?
Thanks
If the original developer used VueJS-cli to develop, you should have the source code at src folder.
The deployed assets are generated in a build phase, and keep apart from source code.
The deployed code is in folder dist in server.
If you only received the dist folder (the compiled assets), maybe it is a difficult to reverse engineer the code, because you only have the minified and uglified version of the source code.
In ASP.Net Core the convention for projects seems to be to put the ASP.Net Core projects inside a src\ folder, and the test projects inside a test\ folder.
What other conventions are there, ie. where should a web (front-end only) project be located?
The honest answer to this is "it depends." The src and test folders at the root are a common structure seen in code repositories today.
Here are some common root folders and what they may contain:
test - Unit tests, UI tests, Integration tests, etc.
src - Source code projects
tools - Strong-name files and/or 3rd party tools that may be used to help tests or builds
build - Scripts to perform various builds on the project
docs - Documentation files for the project
How would you organize a web (front-end only) project inside an ASP.NET Core directory structure?
The only advice I can give without knowing your project, and the people interacting with it, is to keep it simple. I haven't found a need to add more root folders beyond what's seen above.
Keep in mind that there are certain folders that a default project template is going to use:
By default, Grunt is set up to look in the css, js, and lib folders under wwwroot for its bundling process.
Bower (also with the default template) will install packages into the lib folder under wwwroot.
MVC looks through the Views folder for view templates.
I want to start playing with Aurelia and MVC 6 Web API with Visual Studio 2015 RC, and I'm using OdeToCode's blog post as a starting point.
I understand the idea behind the new wwwroot folder, but I'm basically confused as to what should or shouldn't put in there.
My initial thought would to install all jspm packages as well as the actual JavaScript source files outside the wwwroot folder, and then copy with gulp everything that's necessary for running while developing or bundle and copy when deploying.
It would look something like this:
But then again, should I place index.html also in the src folder? and config.js? Or am I actually making my life difficult for myself and should just develop from within the wwwroot folder?
It's the jspm packages that confuse me; it feels wrong to have such a large amount of JavaScript files in the wwwroot when I plan on bundling and minifying anyway.
In short: What would be the preferred folder structure for an Aurelia ASP.NET 5 app in Visual Studio 2015?
I spent quite some time on this and finally settled on:
ApplicationName
src
Api
In here I have an ASP.NET 5 project that provides the api to be consumed by the Aurelia app. You will likely need to turn on CORS to avoid errors.
Client.Web
In here I started with the Aurelia skeleton navigation app. We changed the dist folder to wwwroot. The jspm_packages folder sits outside the wwwroot and the gulp tasks that come with the skeleton navigation app take care of all the copying to wwwroot as needed.
This approch gave me the following benefits:
Clean separation of the api and the client code.
Option to deploy the api and client separately.
Ability to leverage all of the gulp tasks that come with the skeleton navigation app
Clear place to switch over to the Javascript file naming conventions (camelCase)
The drawbacks of this approach:
Starting the full app is more difficult. Currently, I have to click "Play" in Visual Studio to start the api, then I have to start gulp watch. This is not too big of a deal because you can mostly leave gulp watch running the entire time you develop.
For a customer we have an ASP.NET MVC plugin architecture consisting of:
- 1 core web application (this is the root web application in IIS)
- X plugins for which the content (views, css, scripts) are deployed in a sub folder (Areas)
The assemblies of the plugins are deployed in the root bin folder
The plugins are created by separate teams and these teams should be able to deploy a package to a server.
The package (ran by administrators) should make sure the plugin is deployed correctly (in a sub folder of the core) and the dll files should be deployed in the root bin.
I guess a deployment package should be created.
How can this be done or what are good practices around this?
How can I customize the way a package will be interpreted (MSBuild)?
Bit of a late answer, however I have been using a method of creating 'pluggable' areas similar to that discussed here and here.
What these articles talk about is a method to turn areas into separate web projects which can then be bin deployed with the original web app when required.
I have extended their methods with a custom ViewEngine which inherits from the Razor view engine, to look for Views in a specified folder location (I named this folder 'Modules'). This is dynamic based upon whether the modules are included or not (I search for modules in the Modules folder on app_start).
Hope this helps!
I am pretty new to msbuild and aspnet_compiler.
I am using aspnet_compiler to compile web application project. Now I just saw the MSBuild.exe and noticed that its builds my website into the /mywebsite/precompiledWeb folder. Now why do I need to use MSBuild.exe? Can't I directly use the aspnet_compiler to see if my website can be built properly?
(Not sure if I explained it very well).
msbuild.exe is usually used to build projects and its dependencies. When you have a web application project with a project file, vs can use this to build not only your web project but all the dependencies involved. This would only build your source code files, not the markup files (.aspx,.ascx,.etc).
aspnet_compiler is meant to build a web site project that doesn't have a project file. This said, you can also use it to make sure your markup files are also built for your web application project.
You are correct you can manually invoke the aspnet_compiler.exe tool. But better would be to use Web Deployment Projects to help you do this.