Scott Hanselman

ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0

January 19, '16 Comments [308] Posted in ASP.NET | Open Source
Sponsored By

Naming is hard.

There are only two hard things in Computer Science: cache invalidation and naming things. - Phil Karlton

It's very easy to armchair quarterback and say that "they should have named it Foo and it would be easy" but very often there's many players involved in naming things. ASP.NET is a good 'brand' that's been around for 15 years or so. ASP.NET 4.6 is a supported and released product that you can get and use now from http://get.asp.net.

UPDATE NOTE: This blog post is announcing this change. It's not done or released yet. As of the date/time of this writing, this work is just starting. It will be ongoing over the next few months.

However, naming the new, completely written from scratch ASP.NET framework "ASP.NET 5" was a bad idea for a one major reason: 5 > 4.6 makes it seem like ASP.NET 5 is bigger, better, and replaces ASP.NET 4.6. Not so.

So we're changing the name and picking a better version number.

Reintroducing ASP.NET Core 1.0 and .NET Core 1.0

  • ASP.NET 5 is now ASP.NET Core 1.0.
  • .NET Core 5 is now .NET Core 1.0.
  • Entity Framework 7 is now Entity Framework Core 1.0 or EF Core 1.0 colloquially.

Why 1.0? Because these are new. The whole .NET Core concept is new. The .NET Core 1.0 CLI is very new. Not only that, but .NET Core isn't as complete as the full .NET Framework 4.6. We're still exploring server-side graphics libraries. We're still exploring gaps between ASP.NET 4.6 and ASP.NET Core 1.0.

ASP.NET Core 1.0

Which to choose?

To be clear, ASP.NET 4.6 is the more mature platform. It's battle-tested and released and available today. ASP.NET Core 1.0 is a 1.0 release that includes Web API and MVC but doesn't yet have SignalR or Web Pages. It doesn't yet support VB or F#. It will have these subsystems some day but not today.

We don't want anyone to think that ASP.NET Core 1.0 is the finish line. It's a new beginning and a fork in the road, but ASP.NET 4.6 continues on, released and fully supported. There's lots of great stuff coming, stay tuned!


Sponsor: Big thanks to Wiwet for sponsoring the feed this week. Build responsive ASP.NET web apps quickly and easily using C# or VB for any device in 1 minute. Wiwet ASP.Net templates are integrated into Visual Studio for ease of use. Get them now at Wiwet.com.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

WallabyJS is a slick and powerful test runner for JavaScript in your IDE or Editor

January 13, '16 Comments [15] Posted in Javascript
Sponsored By

I was reminded by a friend to explore WallabyJS this week. I had looked at WallabyJS a while back when it was less mature but I hadn't installed a more recent version. WOW. It's coming along nicely and is super-powerful. You should check it out if you write JavaScript. It's also super fast, for these reasons:

Wallaby.js is insanely fast, because it only executes tests affected by your code changes and runs your tests in parallel.

WallabyJS has plugins for the IntelliJ platform, Visual Studio, Atom, and more recently, there's preview support for Visual Studio Code and Sublime Text support is coming soon.

It supports supports TypeScript, CoffeeScript, and ES7. Wallaby supports jasmine for running tests but you can plug in your own testing framework and assertion library as you like.

Installing WallabyJS for Visual Studio Code is very easy now that Code supports extensions.

Installing WallabyJS on Visual Studio Code

Once you've installed the extension it will download what's needed and bootstrap WallabyJS. I did have a small issue installing, but and uninstall/reinstall fixed it, so it may have been just a blip.

Visual Studio Code running WallabyJS

If you want to see it in action quickly without much setup, just clone their Calculator sample at

git clone https://github.com/wallabyjs/calculator-sample.git

Do note that it's not totally obvious once you've installed WallabyJS that you have to "start" its server manually...for now.

Starting WallabyJS

Once it has started, it's mostly automatic and runs tests as you type and save. You can access all WallabyJS's commands with hotkeys or from the Visual Studio Code command palette.

WallabyJS Commands in VS Code

It's great to see a powerful tool like this working in Visual Studio Code. Remember you can get VSCode (now open source!) for any platform here code.visualstudio.com and you can get WallabyJS at their main site.


Sponsor: Big thanks to my friends at Redgate for sponsoring the feed this week.Check out their amazing FREE eBook! Discover 52 tips to improve your .NET performance: Our new eBook features dozens of tips and tricks to boost .NET performance. With contributions from .NET experts around the world, you’ll have a faster app in no time. Download your free copy.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

When did we stop caring about memory management?

January 8, '16 Comments [88] Posted in ASP.NET
Sponsored By

MEMORY! - Image from Wikimedia CommonsThis post is neither a rant nor a complaint, but rather, an observation.

There's some amazing work happening over in the C#-based Kestrel web server. This is an little open source webserver that (currently) sits on libuv and lets you run ASP.NET web applications on Windows, Mac, or Linux. It was started by Louis DeJardin but more recently Ben Adams from Illyriad Games has become a primary committer, and obsessive optimizer.

Kestrel is now doing 1.2 MILLION requests a second on benchmarking hardware (all published at https://github.com/aspnet/benchmarks) and it's written in C#. There's some amazing stuff going on in the code base with various micro-optimizations that management memory more intelligently.

Here's my question to you, Dear Reader, and I realize it will differ based on your language of choice:

When did you stop caring about Memory Management, and is that a bad thing?

When I started school, although I had poked around in BASIC a bit, I learned x86 Assembler first, then C, then Java. We were taught intense memory management and learned on things like Minix, writing device drivers, before moving up the stack to garbage collected languages. Many years later I wrote a tiny operating system simulator in C# that simulated virtual memory vs physical memory, page faults, etc.

There's a great reference here at Ravenbook (within their Memory Pool System docs) that lists popular languages and their memory management strategies. Let me pull this bit out about the C language:

The [C] language is notorious for fostering memory management bugs, including:

  1. Accessing arrays with indexes that are out of bounds;
  2. Using stack-allocated structures beyond their lifetimes (see use after free);
  3. Using heap-allocated structures after freeing them (see use after free);
  4. Neglecting to free heap-allocated objects when they are no longer required (see memory leak);
  5. Failing to allocate memory for a pointer before using it;
  6. Allocating insufficient memory for the intended contents;
  7. Loading from allocated memory before storing into it;
  8. Dereferencing non-pointers as if they were pointers.

When was the last time you thought about these things, assuming you're an application developer?

I've met and spoken to a number of application developers who have never thought about memory management in 10 and 15 year long careers. Java and C# and other languages have completely hidden this aspect of software from them.

BUT.

They have performance issues. They don't profile their applications. And sometimes, just sometimes, they struggle to find out why their application is slow.

My buddy Glenn Condron says you don't have to think about memory management until you totally have to think about memory management. He says "time spent sweating memory is time you're not writing your app. The hard part is developing the experience is that you need to know when you need to care."

I've talked about this a little in podcasts like the This Developer's Life episode on Abstractions with guests like Ward Cunningham, Charles Petzold, and Dan Bricklin as well as this post called Please Learn to Think about Abstractions.

How low should we go? How useful is it to know about C-style memory management when you're a front-end JavaScript Developer? Should we make it functional then make it fast...but if it's fast enough, then just make it work? The tragedy here is that if it "works on my machine" then the developer never goes back to tighten the screws.

I propose it IS important but I also think it's important to know how a differential gear works, but that's a "because" argument. What do you think?


Sponsor: Big thanks to Infragistics for sponsoring the blog this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Best practices for private config data and connection strings in configuration in ASP.NET and Azure

January 6, '16 Comments [48] Posted in ASP.NET
Sponsored By

Image Copyright Shea Parikh / getcolorstock.com - used under licenseA reader emailed asking how to avoid accidentally checking in passwords and other sensitive data into GitHub or source control in general. I think it's fair to say that we've all done this once or twice - it's a rite of passage for developers old and new.

The simplest way to avoid checking in passwords and/or connection strings into source control is to (no joke) keep passwords and connection strings out of your source.

Sounds condescending or funny, but it's not, it's true. You can't check in what doesn't exist on disk.

That said, sometimes you just need to mark a file as "ignored," meaning it's not under source control. For some systems that involves externalizing configuration values that may be in shared config files with a bunch of non-sensitive config data.

ASP.NET 4.6 secrets and connection strings

Just to be clear, how "secret" something is is up to you. If it's truly cryptographically secret or something like a private key, you should be looking at data protection systems or a Key Vault like Azure Key Vault. Here we are talking about medium business impact web apps with API keys for 3rd party web APIs and connection strings that can live in memory for short periods. Be smart.

ASP.NET 4.6 has web.config XML files like this with name/value pairs.

<appSettings>      
<add key="name" value="someValue" />
<add key="name" value="someSECRETValue" />
</appSettings>

We don't want secrets in there! Instead, move them out like this:

<appSettings file="Web.SECRETS.config">      
<add key="name" value="someValue" />
</appSettings>

Then you just put another appSettings section in that web.secrets.config file and it gets merged at runtime.

NOTE: It's worth pointing out that the AppSettings technique also works for Console apps with an app.config.

Finally, be sure to add Web.secrets.config (or, even better, make it *.secrets and use a unique extension to identify your sensitive config.

This externalizing of config also works with the <connectionStrings> section, except you use the configSource attribute like this:

<connectionStrings configSource="secretConnectionStrings.config">
</connectionStrings>

Connection Strings/App Secrets in Azure

When you're deploying a web app to Azure (as often these apps are deployed from source/GitHub, etc) you should NEVER put your connection strings or appSettings in web.config or hard code them.

Instead, always use the Application Settings configuration section of Web Apps in Azure.

Application Settings and Secrets in Azure

These collection strings and name value pairs will automatically be made available transparently to your website so you don't need to change any ASP.NET code. Considered them to have more narrow scope than what's in web.config, and the system will merge the set automatically.

Additionally they are made available as Environment Variables, so you can Environment.GetEnvironmentVariable("APPSETTING_yourkey") as well. This works in any web framework, not just ASP.NET, so in PHP you just getenv('APPSETTING_yourkey") as you like.

The full list of database connection string types and the prepended string used for environment variables is below:

  • If you select “Sql Databases”, the prepended string is “SQLAZURECONNSTR_”
  • If you select “SQL Server” the prepended string is “SQLCONNSTR_”
  • If you select “MySQL” the prepended string is “MYSQLCONNSTR_”
  • If you select “Custom” the prepended string is “CUSTOMCONNSTR_”

ASP.NET 5

ASP.NET 5 has the concept of User Secrets or User-Level Secrets where the key/value pair does exist in a file BUT that file isn't in your project folder, it's stored in your OS user profile folder. That way there's no chance it'll get checked into source control. There's a secret manager (it's all beta so expect it to change) where you can set name/value pairs.

ASP.NET also has very flexible scoping rules in code. You can have an appSettings, then an environment-specific (dev, test, staging, prod) appSettings, then User Secrets, and then environment variables. All of this is done via code configuration and is, as I mentioned, deeply flexible. If you don't like it, you can change it.

var builder = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

if (env.IsDevelopment())
{
// For more details on using the user secret store see http://go.microsoft.com/fwlink/?LinkID=532709
builder.AddUserSecrets();
}

builder.AddEnvironmentVariables();
Configuration = builder.Build();

So, in conclusion:

  • Don't put private stuff in code.
    • Seems obvious, but...
  • Avoid putting private stuff in common config files
    • Externalize them AND ignore the externalized file so they don't get checked in
  • Consider using Environment Variables or User-level config options.
    • Keep sensitive config out of your project folder at development time

I'm sure I missed something. What are YOUR tips, Dear Reader?

Resources

Image Copyright Shea Parikh - used under license from http://getcolorstock.com


Sponsor: Big thanks to Infragistics for sponsoring the blog this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Exploring the new .NET "dotnet" Command Line Interface (CLI)

December 24, '15 Comments [38] Posted in Open Source
Sponsored By

I've never much liked the whole "dnvm" and "dnu" and "dnx" command line stuff in the new ASP.NET 5 beta bits. There's reasons for each to exist and they were and they have been important steps, both organizationally and as aids to the learning process.

My thinking has always been that when a new person sits down to learn node, python, ruby, golang, whatever, for the most part their experience is something like this. It should be just as easy - or easier - to use .NET.

This is just a psuedocode. Don't sweat it too much.

apt-get install mylang #where mylang is some language/runtime
#write or generate a foo.fb hello world program
mylang foo #compiles and runs foo

I think folks using and learning .NET should have the same experience as with Go or Ruby.

  • Easy To Get - Getting .NET should be super easy on every platform.
    • We are starting to do this with http://get.asp.net and we'll have the same for .NET Core alone, I'm sure.
  • Easy Hello World - It should be easy to create a basic app and build from there.
    • You can "dotnet new" and get hello world. Perhaps more someday?
  • Easy Compile and Run
    • Just "dotnet run" and it compiles AND executes
  • Real .NET
    • Fast, scalable, native speed when possible, reliable

I've been exploring the (very early but promising) work at https://github.com/dotnet/cli that will ship next year sometime.

IMPORTANT NOTE: This toolchain is [today] independent from the DNX-based .NET Core + ASP.NET 5 RC bits. If you are looking for .NET Core + ASP.NET 5 RC bits, you can find instructions on the http://get.asp.net/.

Once I installed the "dotnet" cli, I can do this:

>dotnet new
>dotnet restore
>dotnet run

Imagine with me, when you combine this with the free Visual Studio Code editor which runs on Mac, Windows, and Linux, you've got a pretty interesting story. Open Source .NET that runs everywhere, easily.

Here is a longer command line prompt that includes me just typing "dotnet" at the top to get a sense of what's available.

C:\Users\Scott\Desktop\fabulous>dotnet
.NET Command Line Interface
Usage: dotnet [common-options] [command] [arguments]

Arguments:
[command] The command to execute
[arguments] Arguments to pass to the command

Common Options (passed before the command):
-v|--verbose Enable verbose output

Common Commands:
new Initialize a basic .NET project
restore Restore dependencies specified in the .NET project
compile Compiles a .NET project
publish Publishes a .NET project for deployment (including the runtime)
run Compiles and immediately executes a .NET project
repl Launch an interactive session (read, eval, print, loop)
pack Creates a NuGet package

C:\Users\Scott\Desktop\fabulous>dotnet new
Created new project in C:\Users\Scott\Desktop\fabulous.

C:\Users\Scott\Desktop\fabulous>dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16231

CACHE https://www.myget.org/F/dotnet-core/api/v3/index.json
CACHE https://api.nuget.org/v3/index.json
Restoring packages for C:\Users\Scott\Desktop\fabulous\project.json
Writing lock file C:\Users\Scott\Desktop\fabulous\project.lock.json
Restore complete, 947ms elapsed

NuGet Config files used:
C:\Users\Scott\AppData\Roaming\NuGet\nuget.config
C:\Users\Scott\Desktop\nuget.config
C:\Users\Scott\Desktop\fabulous\nuget.config

Feeds used:
https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/
https://api.nuget.org/v3-flatcontainer/

C:\Users\Scott\Desktop\fabulous>dotnet run
Hello World!

Note that I ran dotnet restore once before on another projects so that output was not very noisy this time.

Native Compilation of .NET applications

This is cool, but things get REALLY compelling when we consider native compilation. That literally means our EXE becomes a native executable on a platform that doesn't require any external dependencies. No .NET. It just runs and it runs fast.

It's early days, and right now per the repro it's just hello world and a few samples but essentially when you do "dotnet compile" you get this, right, but it requires the .NET Core Runtime and all the supporting libraries. It JITs when it runs like the .NET you know and love.

.NET Core Compiled EXE

But if you "dotnet compile --native" you run it through the .NET Native chain and a larger EXE pops out. But that EXE is singular and native and just runs.

Native compiled .NET Core EXE

Again, early days, but hugely exciting. Here's the high-level engineering plan on GitHub that you can explore.

Related Projects

There are many .NET related projects on GitHub.


Sponsor: Big thanks to Redgate for sponsoring the feed this week! Have you got SQL fingers? Try SQL Prompt and you’ll be able to write, refactor, and reformat SQL effortlessly in SSMS and Visual Studio. Find out more with a 28 day free trial!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.