Synopsis

Creating a customized version of bootstrap using .less. Overriding base bootstrap styles explained! Can also use .sass instead of .less. But the bootstrap peoples support the .less version directly

Background

What is bootstrap: https://getbootstrap.com/

 

We currently use the bootstrap-less NPM Package.  

 

Less is a “precompiler” language used to define css styles in a programmatic way to reduce redundancies and hopefully make css more maintainable.

 

What is LESS: http://lesscss.org/

 

We mainly just want to import only the bootstrap .less files containing only the features we use, into our own custom version of Bootstrap

 

Usually located:  …\client-assets\less\bootstrap-custom.less

*And thus this file acts as a wrapper for bootstrap AND a place to put custom theme style definitions, optionaly.

 

This file starts with the aforementioned import statements.

 

// Core variables and mixins

@import "../../node_modules/bootstrap-less/bootstrap/variables.less";

... blah blah

 

// Core CSS

@import "../../node_modules/bootstrap-less/bootstrap/scaffolding.less";

... blah blah

 

Then below that, we can apply any “overrides” of the bootstrap .less code or, alternatively, regular CSS code definitions that will override the same definitions declared in the final compiled bootstrap-custom.css file.

 

*That way we don’t touch the original bootstrap source code.  Which will make is seamless for us to drop new versions of bootstrap when they become available.

 

Then later in the file we have:

Ex. less overrides

// Navbar links

@navbar-default-color: #fff;

@navbar-default-link-color: #fff;

 

These are actually originally declared in the node_modules\bootstrap.less\bootstrap\variables.less

When both of these files are compiled by a GULP command, they will be regular css.

And our less overrides (since they appear later in this file) will win out.

Also for regular CSS, later css declarations win over prior declarations with the same name

 

Also later in the file:

Ex.

/*Bootstrap Forms Overrides*/

// override .horizontal-form .control-label to be left aligned

.control-label {

   text-align: left !important;

}

When referencing CSS Stylesheet files

 

Ex.  in the our template _layout.cshtml file or index.cshtml you can declare the following css stylesheets in this order.

 

<link href="~/css/bootstrap.css" rel="stylesheet" asp-append-version="true" />

<link href="~/css/bootstrap-custom.css" rel="stylesheet" asp-append-version="true" />

 

Style Definitions in later files (i.e. bootstrap-custom.css) will always win out.

 

But in our case, our gulp command will actually combine all the imported bootstrap .less files and our bootstrap-custom.less file AND output 1 file that we’ll reference in _layout.cshtml

 

So if a developer modifies the bootstrap-custom.less file, when they are done, they should immediately run in the command line: gulp less

 

This will compile the less and output a .css file in the wwwroot\css folder with the same name:  bootstrap-custom.css

 

Then we ensure we have the reference to our 1 compiled .less file in our html code:

 

<link href="~/css/bootstrap-custom.css" rel="stylesheet" asp-append-version="true" />

 

This process could be enhanced further, and be run on a build server for Continuous Integration/Delivery with your Build Software of choice.  We've used Jenkins.  Can have it dynamically inject the css link into your html file at this time as well. 

If you're a Visual Studio co-dependent like I am, then you live and breath website development from within this code editor environment.  And you may have had aspirations of using something a little more lightweight like Sublime (a little further back perhaps) , Jet Brain's Webstorm, or even Visual Studio Code.  Cuz that's what he cool kidz talk about.  But after the initial excitment of spinning up a new code editor up, do you feel like you're spending way more time staring at the screen rather than coding some code. 

Coding MFucker!

Then itching to get back into your programming comfort zone.  I've been there.  No shame, no judging here.   Although I'm pretty mean with Markdown in some Visual Studio Code - hey it's a start!

Anyways, as I'm doing more and more .Net Core Development (v 2.1 at the time of writing), getting a feel for the ins and out,  I'm everyday peeling myself away from the web server familiar of IIS and it's little cousin IIS Express.  And turning to running the Core .exe process directly.  Known as Project in the...um... project properties.  

Breaking it down now.

 The 3 types of Dev "Web Servers" that you may encounter in .net Core:

  1. Project
    1. Under the hood, running this will call the the command “dotnet run”  (and few other commands internally) from .Net Core Command Line. The result is that this will launch the Kestrel web server.
  2. IIS Express
  3. Local IIS (the classic, baby
    1. Will generate a web.config
    2. Make sure place this web.config in your .gitignore file as it’s more a local user setting thing now

For .net Core projects Local IIS support has to be added into Visual Studio 2017. It's not built in like it is for .Net Framework projects. I'll cover this in a follow up Post.

In your web project's "Properties -> Debug" settings you can create Profiles for these web servers that update a local launchSettings.json file. Here's what it looks like:

web-server-project.PNG

web-server-express.PNG

web-server-iis.PNG

Note: You can create New and Delete profile to the right.

When F5 Debug within Visual Studio, make sure correct Profile is selected at the top!

vs-server-chosen.PNG

Sources:

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-2.1

 

https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-run?tabs=netcore21

https://exceptionnotfound.net/working-with-environments-and-launch-settings-in-asp-net-core