Scott Hanselman

.NET Core 1.0 RC2 - Upgrading from previous versions

May 19, '16 Comments [25] Posted in ASP.NET
Sponsored By

.NET Core at http://dot.net.NET Core RC2 is out, it's open source, and it's on multiple platforms. I'm particularly proud of the cool vanity domain we got for it. http://dot.net. ;) It makes me smile.

Here's the important blog posts to check out:

Head over to http://dot.net and check it out. A great aspect of .NET Core is that everything it does is side-by-side. You can work with it without affecting your existing systems. Be sure also explore the complete .NET Downloads Page for all the manual downloads as well as SHA hashes.

The best way to develop with .NET Core on Windows is to download the Visual Studio official MSI Installer and the latest NuGet Manager extension for Visual Studio. If you don't have Visual Studio already, you can download Visual Studio Community 2015 for free.

We'll have documentation and insights on how to moving from ASP.NET 4.x over to ASP.NET Core 1.0 soon, but for now I've collected these resources for folks who are upgrading from previous versions of .NET Core and ASP.NET Core (the framework formerly new as ASP.NET 5).

Enjoy!


Sponsor: Build servers are great at compiling code and running tests, but not so great at deployment. When you find yourself knee-deep in custom scripts trying to make your build server do something it wasn't meant to, give Octopus Deploy a try.

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 ORCS Web

An update on ASP.NET Core 1.0 RC2

April 14, '16 Comments [90] Posted in ASP.NET
Sponsored By

What's going on with ASP.NET Core 1.0 RC2? Why is RC2 taking so long over RC1 and what's going to happen between now and the final release? I talked to architect David Fowler about this and tried to put together some clear answers.

This stuff is kind of deep and shows "how the sausage gets made" so the TL;DR version of this is "the guts are changing for the better and it's taking longer than we thought it would to swap out the guts."

That said, ASP.NET Core RC2 has some high level themes:

Re-plat on top of the .NET CLI

This is the biggest one and there are quite a few changes and tweaks made to the hosting model to support this. The way your application boots up is completely different. I'd encourage you to take a look at the https://github.com/aspnet/cli-samples. Some of the changes are very subtle but important. We baked a bunch of assumptions into DNX specific for web applications and now we're building on top of a tool chain that doesn't assume a web application is the only target and we have to account for that.

There were a couple of fundamental things affected by this move:

  • Acquisition
    • How do you get the tool chain and shared runtime?
  • Runtime
    • The API used to find dependencies at runtime ILibraryManager
    • The API used to find compilation assemblies at runtime ILibraryExporter
  • Tooling
    • There's no dnvm replacement
    • Visual Studio Tooling (UI) support needs to use the new CLI
    • OmniSharp needs to use the new CLI
    • What's the dnx-watch successor?

The list goes on and on. I'd suggest watching the ASP.NET Community stand up as we're pretty transparent about where we are in the process. We just got everyone internally using builds of Visual Studio that have CLI support this last week.

The new .NET CLI (again, replacing DNX) will be the most de-stabilizing change in RC2. This is a good intro to where things are headed https://vimeo.com/153212604. There's been tons of changes since then but it's still a good overview.

Moving to netstandard

This has been a long time coming and is a massive effort to get class library authors to move to the next phase of PCL. This is critical to get right so that everyone can have their favorite packages working on .NET Core, and as such, working everywhere. 

https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Class-Libraries

https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

.NET Standard Library means a modular BCL that can be used on all app models

Polish

We're looking at all of the patterns that we have invented over the last 2 years and making sure it's consistent across the entire stack. One example of that is the options API. We went through the entire stack and made sure that we were using them consistently in middleware and other places. That is a breaking change but it's an important one.

Other examples of this include things like making sure we have the right extension methods in places and that it looks like they were designed in a coherent manner (logging is an example).

Other small things:

  • Remove the service locator pattern as much as we can. Some of this requires API change.
  • Making sure we have the right set of DI abstractions so that DI vendors can properly plug into the stack.
  • Taking the time to look at feedback we're receiving to make sure we're doing the right things. This is ongoing, but if there are small changes we can make that solve a common issue people are having, we'll make that change while we still have this freedom.
  • Change how we plug in and configure servers in our Hosting APIs https://github.com/aspnet/KestrelHttpServer/pull/741

Fundamentals - Stress, Security, Performance

This is always ongoing but now that most of the features are done, we have more time to spend on making things like Kestrel (the web/app server) rock solid and secure.

We're also doing more stress runs to make sure the stack is very stable memory wise and to make sure nothing crashes .

More Performance

This is part of fundamentals but deserves to be called out specifically. We're still making changes to make sure things are very "performant." Some of these are tweaks that don't affect consuming code, others are actual design changes that affect API. MVC is getting tons of love in this area (https://github.com/aspnet/Mvc/pull/4108). HttpAbstractions and other higher level APIs are also getting lots of love https://github.com/aspnet/HttpAbstractions/pull/556 to make sure we reduce allocations for things like file upload.

We're also looking at higher level scenarios to make sure that not only focusing on microbenchmarks. You can see some of them at https://github.com/aspnet/Performance/tree/dev/testapp.

Techempower is still on our radar and we're running the plain text benchmark on similar hardware now and comparing against the competition (we're in the top 10 right now!) and we'll hope to be there and official for RTM.

I hope this gives you some context. We'll cover this and more every week on the Community Standup as we move towards RC2, then on to RTM on three platforms!


Sponsor: Big thanks to RedGate and my friends on ANTS for sponsoring the feed this week! How can you find & fix your slowest .NET code? Boost the performance of your .NET application with the ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free

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 ORCS Web

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

January 19, '16 Comments [319] 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 ORCS Web

When did we stop caring about memory management?

January 8, '16 Comments [90] 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 ORCS Web

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

January 6, '16 Comments [50] 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 ORCS Web
Page 1 of 167 in the ASP.NET category Next Page

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