Core/Razor Pages - The Bleeding Edge of MVC

Introduction

I admit it, I'm probably only barely functional in terms of web development, and what I'll be talking about is relatively new stuff, but I still expect things to work a certain way, and am dismayed, annoyed and even pissed off when they don't. Enter ASP.NET Core 2.1 Razor Pages.

I'm working on a web app solution that contains several closely related web apps. As you might guess, I want them to all look pretty much the same.  To that end, I a number of css files, images, and partial views that I'd like to use across all of the web apps.

I suppose you could view this tip as more of a rant than anything else, but since I'm sharing info that I've discovered over the last few days, I think it qualifies as a tip.

Razor Control Libraries

So, after my adventure with adding files as links, I decided to try using a "Razor Colass Library". At first blush, it appears to be a suitable method for oproding globally used files. Afterall, an RCL project contains all the same folders as a Razor Pages web app. What could possibly go wrong? Well, sit right there and I'll tell you. You have to MANUALLY modify your RCL project file, add a routing class to your web app projects, and then override the projects to use the new routing class instedd of your normal (generated) routing code. This is only guaranteed to work for javascript, too. No telling what will happen if you try to do it with style sheets, images, or partial views. The short version is, don't waste your time, because the juice just ain't worth the squeeze.

Bundling (old MVC paradigm)

Bundling is not really supported like we know and love/hate in MVC. You have to edit the jsonconfig file for the app, and jump through just as many hoops as tryign to yuse a RCL, and that seemed too bulky, as well as fraught with danger due to the number of backflips you must perform to get it to work.

Using a "Common" Folder

This was actually my first attempt at having globally accessible resources was to create a Common folder in the root solution, and place all of my "common" files in that folder. Once they're in the folder, I could add them (as a link) to the various projects that would use them.

The problem with this approach was hat once added to the projects, you have to MANUALLY go to the properties of each common file (in the project that uses them), and set the file as "Content" that is "Not copied". If you don't do that, your web pages won't be able to find the files. And before you try it, you can't set the files in the "Common" folder with the correct property values. Instead, you have to wait until you've linked to them in your project(s), and change them one at a time.

Another thing regarding solution folders as described above - the folder might exist in the Solution Explorer pane, but it is NOT a physical folder on the file system. When you create files in the common folder (in Visual Studio), they are placed in the solution's root folder instead of in the folder specified in the project. In my case, the Common folder. 

If you want a physical folder in the file system, you have to create it in the solution's root folder, and then add it via Visual Studio. Oh, and by the way, don't bother giving it a name that you think might be appropriate. When you add it to the solution, the solution will call the folder Solution Items. To avoid future confusion, just name your folder "Solution Items". From that point on, you can create a normal folder hierarchy to separate file types.

CAVEAT: I have established that the "common folder" idea works well for partial views. CSS files don't work (see next section for a workaround), and I haven't tried images or javascript - yet. IMHO, the CSS thing is a bug. Will Micerosoft admit to it and fix it? Probably not in VS2017, since they're already releasing VS2019 RC's.

CSS Huzzahh!! Moment

I discovered that adding css files (as link) from your common files folder is problematic. NO MATTER WHAT YOU DO, the css files are not compiled with the rest of the project (or loaded).  My ultimate solution was to create a partial view in the common folder that contains a style element, into which I copied all of the style definitions from my original style files (yes, I had more than one). I then simply need added the following to my _Layout file <code>head</code> element:

<partial name="_SharedStyles" />

Points of Interest

I realize we could put scripts and style sheets on a CDN, but my goal is to keep everything in the solution to make deployment less of a hassle. That being said...

The most glaring point of interest is that Microsoft STILL has not realized that we, as developers,  expect certain things to be automatic. Like setting appropriate file properties, or making a RCL automatically allow the sharing of static files, such as style sheets, images, and so on and so forth. Why, in our enlightened state, do we have to fight this hard with tools that are supposed to make our lives easier?

What you're witnessing here is the cost of being on the bleeding edge of new development. Will they make it better? Maybe, but probably just before they abandon the technology for something new, most likely dealing with writing code simply by farting. 

Still a Bit of a Hassle...

I found that the best way to add a new file to yopur common files folder is to go to explorer, browse to your common files folder, create a new text document with the correct extension (.cshtml for partial views), and then go back to the IDE and Add Existing Item. At that point, you can add the code for your partial view.

History

2019.01.31 - Added the Huzzah Moment section to make this tip more tip-like.

2019.01.27 - Initiale publication