.NET Full Framework issue when referencing .NET Standard 1.4 library

If you get an error message when you try to reference your .NET Standard 1.4 library from a .NET full framework app (like .NET 4.6.1) you may see this error message: System.IO.FileLoadException : Could not load file or assembly 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

The issue is there’s a bug with the System.Net.Http 4.3.0 package.  The fix then is to install System.Net.Http 4.3.1 in your .NET Standard library.  So your csproj should look like this:

<ItemGroup>
    <!-- Add 4.3.1 version explicitly. -->
    <PackageReference Include="System.Net.Http" Version="4.3.1" />
    <!-- Any other packages here. -->
</ItemGroup>

Now you should be good.

There are a lot of threads on GitHub about this on many different repos, but this fix is only in one of those threads and so I thought I’d post this to make it easier for the next person.

Exploring the Environment Tag Helper exclude and include attributes in ASP.NET Core 2

tldr;

A new exclude attribute on the EnvironmentTagHelper lets you easily tell the EnvironmentTagHelper to render in all Environments EXCEPT the one(s) you specify. There’s also a new  include attribute that behaves the same as names did in ASP.NET Core 1.

A comparison between ASP.NET Core 1 and 2:taghelpers

 

Environments in ASP.NET Core

In ASP.NET 4 (and previous versions), there was no concept of an Environment.  Even though in almost every job, there are the concepts of Environments such as Dev, Staging, UAT, QA, Production, etc.  You were essentially on your own to implement your concept of Environments.  Sometimes enlisting the help of something horrible like compiler directives.

In ASP.NET Core, they built the Environment concept right into the stack.  There are 3 Environments by default – Development, Staging, and Production, but you can add your own custom ones if you want.  The Environment is controlled by an Environment variable called ASPNETCORE_ENVIRONMENT.  This allows you to inspect the current Environment using an IHostingEnvironment and run code like this:

You can find more on Environments on the official documentation here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments.

 

Environment Tag Helpers in ASP.NET Core 1

Besides using IHostingEnvironment, In ASP.NET Core 1 you could conditionally load some markup based on the Environment you were in via an EnvironmentTagHelper.

But that was a little brittle, given you can make your own custom Environments, in addition to the built-in Development, Staging, and Production Environments.  Essentially, if you introduce a custom Environment, then you have to CTRL + F for all your EnvironmentTagHelpers and add in your new custom environment.  That’s a real pain.

 

Enter include and exclude attributes on the Environment Tag Helper in ASP.NET Core 2

To solve this, the ASP.NET team introduced the include and exclude attributes on the EnvironmentTagHelper.   Let’s look at exclude first.  

Exclude does about what you would think.  It will only render the contents of the EnvironmentTagHelper if the current environment does NOT match the Environment specified.  So <Environment exclude="Development"> would NOT render the contents in Development, but would render in any other Environment (such as Staging, Production, or a custom Environment you specified).

Include, on the other hand, operates the same as the names attribute we had in ASP.NET Core 1.  It’s just there to provide consistent naming as the opposite of ​exclude.  It will only run if the current environment DOES match the Environment specified.

So those used together would look a little something like this:

 

The names attribute still exists… but don’t use it

The names attribute still exists for backwards compatibility, but I don’t see a reason to use it anymore over include.  I don’t have a crystal ball, but I’d say it’s likely names will be removed in a later version of ASP.NET Core now that we have include and exclude.  Although the team seems committed to backwards compatibility at this point in time.

Personally, I think it’d be cool if the ASP.NET team shipped codemods in the form of Roslyn Analyzers to auto upgrade your code to the latest API’s, and then just make a clean break.  In this case, anywhere you’d use names would automatically upgrade to use include.  As a developer, you could still inspect the changes the Roslyn Analyzer made when reviewing your Commit/Pull Request to make sure the Analyzer did the right thing.  The React team at Facebook does this, but they also have a financial incentive to ship upgrade-friendly stuff like that when Facebook has over 10M lines of code.  So…. yeah…

 

What if I use include and exclude in the same Tag Helper and use the same Environment in both?

If you screw up like this, ASP.NET Core will do the “safe” thing by default and NOT render in that environment.  This is very similar to how NTFS works where a deny will take precedence over an allow.

So if you do something like this:

Then the content will not show in the Development or Production Environments, but it will show in Staging, since it is part of the include and not in the exclude.

In real life, I don’t know why you’d use both together.  I would always just pick a whitelist (include) or a blacklist (exclude).  But it’s probably a good thing to keep in mind.

 

Closing

This will make life so much simpler to deal with the EnvironmentTagHelper especially when used with custom Environments.

If you’re interested in the ideas they threw around to solve this problem, before ultimately landing on include and exclude, you can read the GitHub issue here. You can also see the commit that went into making this feature work.

I was playing around with ASP.NET Core 2.0 before I give a talk on what’s new on it in 4 days, and I came across this and just had to share… now it’s back to rehearsing!

Prettier + Format On Save = Never worry about formatting JavaScript again

In my last post, I mentioned a tip to using the Format on Save option in VS Code.  I’d like to take that one step further and mention how you can combine that with the Prettier – Javascript Formatter plugin for VS Code to make a really nice editing experiencee.

 

What is Prettier?

Prettier is an open source project (originally started by James Long) that is an opinionated JavaScript formatter.  Prettier takes JavaScript code in, runs some of its formatting rules against it, and then spits that JavaScript code with its formatting rules applied.

One of the things I love about it is it’s not rigid with its rules.  It makes some “logical” choices that I would make myself.  For instance, Prettier will make a short const array declaration a one liner, but a declaration with a bunch of items in the array, it will split out into multiple lines to avoid horizontal scrolling (see demo GIF at the end).  I love that.

While I only mentioned JavaScript so far, technically Prettier can do more than just JavaScript.  It can do CSS, LESS, SASS, TypeScript, and JSX as well.

 

VS Code Integration

The Prettier -JavaScript Formatter plugin for VS Code simply shells out to Prettier, as well as it exposes some settings that you can override in your settings.json.  It also respects the Format on Save option I mentioned in my last blog post.

 

Overriding Prettier settings in VS Code

By default Prettier uses 2 spaces for tabs.  You can increase that to the VS Code default of 4 if you want extremely easily:

  1. Hit CTRL + , or Command + , on Mac to bring up the Settings.json
  2. Search for Prettier
  3. Click to the left of prettier.tabWidth on the left hand side and click Copy To Settings
    1. 2017-06-09_22-15-33
  4. On the right side so you can change it to 4 and then hit Save to save your settings.json file.

 

You can scan the rest of the prettier options that show up in the search to see if there’s ones you want to override.

 

Formatting is something I never worry about anymore

I find when using Prettier, along with the Format On Save option in VS Code, I don’t think about how to format my code anymore.  I don’t ever wonder “oh should I put this on multiple lines or keep it all in one line?”  Instead, I focus on solving my problem, hit Save and let Prettier do the rest.  It’s shocking how liberating this is.  I end up with consistent formatting across my entire project instead of just doing whatever I felt was best at the time.

 

Prettier in Action

Prettier

Quick VS Code Tip – Format on Save

Rather than Formatting your code using Shift + Alt + on Windows or on Shift + Option + on Mac, consider just formatting on save instead.

To turn this on go to:

  1. File
  2. Preferences
  3. Settings
    • Or just hit CTRL + Comma on Windows to bypass steps 1-3
  4. search for editor.formatOnSave and change that to true
    • Note: this UI is a little confusing. The left side is the default settings and the right side is your custom settings you’ve overriden.  You can either copy the setting over to the right or hover over the setting on the left and click the pencil and select true.
    • 2017-06-05_9-35-18

Quick Visual Studio Tip – Delete to End of Line

There are tons of times where you want to delete from the right of your cursor, while preserving everything to the left of your cursor.

Today the most common way is to do SHIFT + END to highlight it all and then hit DEL, such as below.

endoflinedelete

However, there’s a way to delete to the end of the line by binding a keyboard shortcut to Edit.DeleteToEOL.  By default this is not bound to any keyboard shortcut, so you’ll have to pick one.

If you haven’t overrode a keyboard shortcut before, you can go to Tools => Options => Keyboard, and then type Edit.DeleteToEOL in the “Show commands containing” text box.  You can then type a keyboard

I removed all previous bindings to CTRL + L and bound Edit.DeleteToEOL to that, but you can pick whatever you want.

2017-05-29_14-37-42

Now when I hit CTRL + L it removes everything after my cursor, saving me some keyboard strokes.

endoflinedelete2

Hope this helps.