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.
Related
I have multiple projects in the same folder, each of them creates a microservice. Each has a separate build and release pipeline. Currently each project is configured so to trigger when code is committed in its own sub folder. I am currently in the process of adding some common code which is used in some of the projects. I would like for a microservice to build and deploy if it uses a library that is being changes.
What is the best way to achieve this?
Ideally, I imagine something like this:
Build task which triggers on root directory -> Use MsBuild to determine if a project needs to build, by checking its dependencies -> Build/Abort.
Is this possible?
If you want to share code in source form and you are using .NET Framework projects, the best (but not optimal) approach that I found is to have the projects in the same folder and put the shared code in a subfolder that you include in both projects. To put shared code in a folder outside the root folder of a project is even worse.
The best approach (IMO) is to share code in compiled (Dll) form (rather than in source form): you can create a DLL with the shared code, package it in a NuGet package, and publish the NuGet package in some internal NuGet repository (for example, you can use the Artifacts feature of Azure DevOps as NuGet repository for your organization). The projects that require the shared code do it through NuGet references. The advantages is that the shared code in Dll/NuGet form can be versioned (not all projects must be updated at the same time for incompatible changes), it can use its own CI pipeline with unit tests, it can use its CD pipeline to publish to the Artifacts repository, etc.
I switched from the former approach to the latter. Much cleaner IMO.
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'm using YUI Compressor as a MsBuild Task on my Azure project. It works well on locally but when I try to publish it I cannot insert minified packages to my azure application package. Although I have tried a lot of things about package modifying on my .csproj file I couldn't work it out. How can I do this?
Edit:
My project is not a MVC or Webforms application. Just HTML and Javascript inside of an ASP.NET project. My problem is not minification. It is just placing minified external files in Azure Package when publishing it but if there is any other method that solves this azure problem, I can change YUI Compressor with ajaxmin or google closure... doesn't matter.
I don't think modifying the service package is supported (you are also modifying the manifest). That's why I would look at it from an other perspective. I'm assuming you have such a setup:
Solution
Empty ASP.NET Project
Index.html
App.js
Now, after you compile (and the MSBuild task runs) you'll have something like this:
Solution
Empty ASP.NET Project
Index.html
App.js
App.min.js (not included in the project, but available on the file system)
Now, buy simply including the App.min.js file in the project, it will be included in the service package when packaging or publishing your application. And besides that, the MSBuild tasks runs each time you compile, meaning the file will be updated before each time the application is packaged.
As you haven't specified about about whether it is WebForms or MVC, I would like to point out the out of the box support for the bundling and minification in ASP.net MVC4. Scott Gu has explained it the MVC4 preview demo.
You can also tweek it to work a way for that in ASP.net MVC3 too. Once this is achieved, you can achieve that in Azure as well.
Additional Articles :
ASP.NET MVC4 bundling in ASP.NET MVC3
New in ASP.NET MVC4: Bundling and Minification
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.