Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

ASP.NET Core and .NET Core Overview


It’s been a long journey, but ASP.NET Core and .NET Core have been released as v1.0 RTM this week. Yay! Congratulations to the ASP.NET and .NET Core teams on building this massive framework and delivering what looks to be a solid 1.0 release.

A lot has changed since I wrote my first articles for ASP.NET ‘vNext’ in Code Magazine which were my first takes on the platform late in 2014. In this post I’m going to revisit the high level overview architecture of .NET Core and ASP.NET Core since so much has changed, to help you understand how the pieces fit together and what it means to develop on the new stack along with some personal thoughts on how I plan to approach all of this new tech in my own work.

It's been a long Wait

The last couple of years have been tough if you’ve been keeping up with Microsoft’s ever changing architectures for the new .NET and ASP.NET platforms. The .NET Core platform has gone through three major platform updates since this journey to reboot .NET started nearly 3 years ago, but now it finally seems that all of this churn is coming together in a much clearer vision of where .NET is headed. Even so not all of this unification and integration is going to come to fruition with the forthcoming RTM release, as more post RTM changes have already been announced. Rather, RTM for .NET Core and ASP.NET Core will be more of a stepping stone on a longer journey that continues to add new features as time goes on.

Drawing a line in the Sand

This initial release is about drawing a line in the sand and having a stable base on top of which additional frameworks and components - and updated features - can be built. It's also a stake to let people start using an official released version of these new tools. Microsoft is quite adamant in saying that although there will be a lot more changes post RTM, these changes are not going to be as drastic as some of the changes that we've seen as late as RC2. Instead future changes are supposed to light up new functionality that won't break backwards compatibility. More features available without breaking what's already there.

v1.0 has released with solid tooling infrastructure and a solid but ‘snapshot in time’ version of the .NET Core framework and a fully functional ASP.NET MVC application layer.

Of these major components the one most in flex is .NET Core, which is going to gain additional features to bring it closer to the full .NET framework after the RTM release. The v1.0 release is meant to bring a production ready and fully supported release of the .NET Core and ASP.NET Core systems so that early adopters have a solid, base production framework that is officially supported by Microsoft to deploy applications with.

But make no mistake - things are going to continue changing after RTM. But hopefully if we take Microsoft's word, the changes coming post RTM will be benign to existing code.

Building a Common .NET

With .NET Core and ASP.NET Core Microsoft is on a mission to build a unified .NET base library that provides a common baseline that all platforms that run .NET can take advantage of. Today there are a boatload of different .NET implementations and each has its own set of supported features. If you are a component developer today (pre-Core) it's very difficult to build libraries that can run on any number of the supported platforms.

Microsoft has been proposing to create a new .NET Standard, which is a 'standard' that defines a common base layer that a platform should support. They plan to implement this new .NET Standard across the runtimes Microsoft itself publishes. It's very likely that ultimately .NET Core - which is an implementation of .NET Standard - will figure heavily in this vision, with .NET Core providing a single implementation that can run on many platforms. We're already seeing that with support for .NET Core on Windows, Mac and Linux for the server version. But there are more OS's to worry about - Xamarins Mobile platforms running Mono, UWP Windows application, game development platforms and the desktop OS implementations that are currently served by Mono.

.NET Core is the vehicle to deliver on the .NET Standard and while it hasn't been officially stated, it's probably a safe bet that .NET Core will become the unifying runtime that eventually can span a server/desktop based runtime (what .NET Core does today), UWP Windows apps and what currently is Xamarins stack as well as the desktop OSs that Mono targets. This isn't all going to happen overnight and certainly not with this v1.0 RTM release, but with ASP.NET Core and .NET Core you're getting the clearest glimpse of what that world will look like today.

.NET and ASP.NET Core today

As of today (.NET Core/ASP.NET Core RC2) the landscape is still pretty fragemented:

.NET Platform Infrastructure today
slide slightly modified from previous Microsoft presentations from Scott Hunter and Jeff Fritz

On the bottom you have the core infrastructure of compilers, languages, runtime and tools that interact with them. Above that sit the base libraries, which is where most of the divergence that we are seeing today is centered on, due to the variety of different runtimes that all have different feature sets with some partial overlap. Above that sit the application frameworks like ASP.NET Core, Xamarin's mobile libraries and desktop Windows platforms like WPF, WinForm as well as full framework ASP.NET.

.NET Common Infrastructure

On the bottom of the stack you have the common infrastructure and tools that provide the base rock of the platform: The Roslyn Compiler platform, C#, VB.NET, F# and the runtime loaders and the new dotnet.exe based command line tools. This story is actually much better today than it was just a couple of years ago thanks to Roslyn's unifying influence that has made much easier to take advantage of the compiler as a platform. Alternate platforms can now much more easily use Microsoft compiler rather than reinventing the wheel including running the compiler on non-windows platforms. .NET Core on Mac and Linux uses Roslyn for example as do tools like Ominsharp.

The important thing about this base is that it provides a single set of tools to get started with .NET both as a developer and integrator. In this scenario .NET is installed from a single .NET SDK. Once the SDK is installed you can create a new project from the command line, compile it and run it all with a few very simple steps. As part of configuration you can specify which version of the .NET platform you want to target and the compilers will figure out how to build and run the proper version(s) using the correct runtimes.

You don’t need Visual Studio or install a host of other .NET SDKs – all that’s needed is the single .NET SDK that gets you everything you need to do it all. This common set of tools can be used to build, package, and deploy applications as I’ll show later in this article.

This may not seem very significant at first glance, but if you compare this to the process of getting started with full framework .NET today, this is a big step forward. Rather than installing the huge monster that is Visual Studio that gives you everything under the sun, or installing a host of disparate SDKs and support tools, a single reasonably sized SDK install gets you everything you need to build and run any kind of .NET application. You can get started with .NET within a few minutes of download and a short install.

To be clear – we’re not there yet as support for .NET Standard currently is limited to .NET Core applications at the moment, but if you’re building apps with ASP.NET Core or .NET Core you can see what this developer experience looks like. You can use command line tools, or you can use Visual Studio. You can use your favorite editor including editors on other platforms and use tools like Omnisharp to get a pretty good .NET dev experience outside of Visual Studio. Visual Studio still provides the richest environment for .NET development, but you can get the compiler and tools integration and a good chunk of the editor and Intellisense smarts in other environments now as well.

Command Line Tooling

The dotnet.exe command line tools combine compiler, runtime loaders, package management and deployment into a single, easy to use environment that is accessible with single commands that are easy to work with even for command line adverse developers. Personally I'm not that keen to work from the command line only, but I really love the fact that I have access to all of these tools so I can automate my build and deploy steps much easier than before. While I am no command line lover I definitely have been using the CLI a lot. Using these tools will change the way you think about the tools and it's very likely it'll also change the way you work with some things. I know it has done that for me.

When you install the SDK the dotnet command line tool is referenced in your path. You can say dotnet new to scaffold a simple HelloWorld console project that you can modify and edit in a plain text editor. You can then do dotnet restore to restore missing NuGet packages including runtimes, followed by dotnet run to execute the application. dotnet build and dotnet pack can build and package your application and component packages for binary distribution and nuge t packages, and finally dotnet publish can deploy an application to a server or other packing location.

This simple command line front end interface consolidates a ton of disparate tooling under a single installable package, which makes it much easier to get started with .NET. And to top it off, these tools work the same on all the Operating Systems that .NET now supports: Windows, Mac and Linux. This tooling significantly lowers the barrier of entry to starting with .NET regardless of the platform you’re using.

Base Class Libraries

In the current state of .NET there are a lot of different yet similar .NET runtimes. There’s the full framework .NET library, the .NET Core library and there’s Mono that’s used for mobile and Mac development with Xamarin. Then there are various older libraries like Silverlight, Windows Phone 8 and 8.1 etc. Tons of libraries – all similar, providing common .NET functionality, but all with different levels of feature support. For developers and especially component developers it has been a major headache to support so many variations of .NET.

.NET Core is the key for Microsoft’s journey to moving to a single .NET Standard which is meant to provide a core base line for the .NET framework across all platforms which is shown below:


slide slightly modified from previous Microsoft presentations from Scott Hunter and Jeff Fritz

Please note that .NET Standard roughly corresponds to the core system services in the .NET Framework which equates to what is in mscorlib or the BCL today. In full framework there is also the FCL which are the various System assemblies, many of which are platform/Windows specific and these libraries are not coming to .NET Core, at least not in the core runtime. The idea is that there is a core layer that is maintained as a single runtime, but everything else sits on top and is developed and delivered separately.

If .NET Standard delivers on the promise of providing most of what mscorelib provides and provide that across multiple platforms with the .NET Core implementation that would be a huge improvement over the somewhat limited and often incompatible (with full framework) subset we see in the current RC2 bits.

We’re not there yet obviously, but the .NET Core stack with ASP.NET gives us a good glimpse of what development looks like for all platforms using .NET Standard.

Application Libraries

The push for a standard .NET library makes it much clearer where the boundaries are between the base library and the application layer. Since the standard library has to be able to run cross-platform a lot of feature functionality like OS specific library features have to move higher up the stack into the application frameworks. To be clear what the .NET Standard Library addresses is akin to what was called the BCL (Base Class Library – the stuff in mscorlib.dll) of old. Additional services that traditionally were services of the FCL (Function Class Library) have to move up to the specific framework/application layer.

For the full .NET framework this includes common applications frameworks we use to build desktop and server applications with. WPF, WinForms, Console apps, Services and ASP.NET apps of all stripes.

It's important to note that the full .NET framework 4.x does not go away. It will continue to be delivered and improved on with its Windows centric focus and support of all the Windows specific and rich application features that you are using today. This means you are not required to move to .NET Core or ASP.NET Core – your existing applications and new applications build with ASP.NET MVC 5 will continue to work and are still viable for new projects going forward for a long time.

Microsoft is also comitted to continuing to support and improve full framework, although it's clear that all the big exciting stuff is going to be happening on the .NET Core platform. ASP.NET Core is the application framework that is getting a lot of attention because it is one of the first big frameworks built on top of the .NET Core framework using the current .NET Standard Library implementation.

Xamarin

Finally, on the right we have Xamarin and the various client and mobile platforms which to date are based on Mono. Mono is a port of the full .NET framework that runs on Mac, Linux, Android and iOS. Since Microsoft has acquired Xamarin recently Mono and .NET Core are starting to converge and it’s expected that eventually Xamarin based tools will use .NET Core as well or Core and Mono end up merging to the point where you can't tell the difference.

Bringing it all together

In the end the idea is to bring all of these disparate platforms together more closely with a common base line of the .NET Standard that is the same on each platform, which makes it easier for both implementors and developers to jump from platform to platform. It's hard to say whether Microsoft and other platform vendors can deliver a runtime that satisfies all platforms. Only time will tell.

But things are looking much more promising than they have at any time during this long development process to bring out .NET Core and ASP.NET Core. It's a monumental job that has been accomplished thus far, given the sheer scope and size of the .NET libraries that have been ported and created.

And more importantly in my opinion: It seems that Microsoft finally has a coherent vision for .NET that isn't just full of catchy phrases and technologies du jour, but rather a strategy to make sure that there is consistency when you use .NET on various platforms. Hopefully Microsoft can also undo the mis-marketing and terrible messaging that has surrounded .NET for so long and has undoubtedly massive harm over the years. Just hearing recent talks that discuss .NET from build and forward I think this is also changing with coherent messages finally emerging.

It's also very clear that the move to open source development has drastically changed the way things are done at Microsoft and you can see this in the excitement of the developers and the sheer active involvement both by members of Microsoft teams as well as the open source developer community. If you check the repositories and activity it's intoxicating to see the rush of activity. A lot of this can be attributed to the modularity that allows small teams to tackle small and very focused tasks which promote a stake in the technology to be proud and exited about for devs which is ultimately what drives better development.

Should I stay or should I go?

Whenever a discussion of this new technology comes you can't get away from the question of whether it's a good idea to jump in, or wait a bit to use all this shiny new functionality.

There are no easy answers for this and even when RTM rolls around, it won't be anything like the minor updates to ASP.NET/NET technology we've seen in the last years.

I think building a real world .NET Core based ASP.NET Core apps today will be a tough job due to limited third party support. Most of the applications I build today use a number of third party libraries. Many of those are not available yet in .NET Core versions with many (including some of my own) not even having a schedule to port. A few examples that come to mind are BrainTree SDK, XmlRpc (MetaWebLog), Graphics libs (no System.Drawing), Email, FTP, Libs, MongoDb just to name a few. Some of these don't have good workarounds today. BrainTree for example doesn't have an official API spec - they provide only their vendor ,SDK otherwise you have to reverse engineer their internal REST calls. Or XmlRpc - that project hasn't been updated in 7 years. It was done then (fair enough) but that's not going to work for .NET Core without some additional work.

What this means is that if you run into soemthing that you assumed would be there and isn't you're looking at finding an alternate library (if you're lucky) or hacking together your own, or fixing an existing library to support .NET Core none of which are very enticing.

Library developers too are likely to look at the recent announcements that more of the full framework .NET Stack is moving into .NET Core. And if so it'll likely be a heck of a lot easier porting libraries in the future than right now.

Full Framework MixIn?

Although Figure 2 doesn’t describe this use case well, ASP.NET Core can also use the full .NET framework to run ASP.NET Core applications.

But even if it is possible to do so, I think that this is not the optimal use case for ASP.NET Core. If you are considering ASP.NET Core most likely you are considering it for its new features like reduced footprint, high performance infrastructure and the cross platform capabilities. If you use the full framework with ASP.NET Core you're giving up many of those new features and the benefits of this new platform are somewhat diminished.

You do get to use ASP.NET Core, though, along with the new Dependency Injection based configuration and everything else that is new. But you can't run on other platforms obviously and you're going to actually increase your memory usage as you are loading multiple frameworks that are interacting with each other.

While possible, I question this path as it feels like the kind of legacy integration path that you will kick yourself for in a year or so as the technology comes to full fruition as additional features in the framework light up and third parties fill most if not all feature voids. To me, if I'm going to invest in this new way of building applications it's all or nothing - the safe path in the middle feels more like the training wheels you won't be able to kick off when you're half way down that rough hill.

Jumping in - slowly...

Personally I really like what I see in ASP.NET Core - especially the integrated MVC/API features, TagHelpers, ViewComponents, the new Config system to name a few. But I'm also wary to jump in with big production apps and I'm holding off for those projects. Most of my customers are also not ready to live on the bleeding edge either where you can't yet tell where the pain points will be because the landscape is still shifting. Most of these customers are likely to wait until at least the next major release. I won't be surprised to see many others on the fence as well. The reality is that ASP.NET Core and .NET Core are a pretty major change and with those changes combined with the prospect of missing features and low third party support the initial release is not an easy sell.

So, am I using ASP.NET Core today? Yes, I have a few sample apps I've been nurturing since the early betas and I've been updating and tweaking those and the final update to RTM from RC2 was relatively minor. A couple of weeks ago I also started a couple of small to medium sized internal projects with ASP.NET Core. Chosen specifically because they don't require anything in the way of integration so they should be safe for use with .NET Core's smaller API footprint.

For me personally I like to cut my teeth on the technology in a non-mission critical environment. Learn and figure out best practices and then eventually kick it up to high gear. I can say that the projects I've been working on are stable and performance is decent (although slower than classic ASP.NET apps). The tooling is not all there and it takes some tweaking to do things like publishing to IIS, but I'm guessing that some of these pain points will be routed out by the time RTM is shipped.

In the end I think Microsoft is going to deliver exactly what they are promising for RTM. A stable release of .NET Core and ASP.NET Core that is a snapshot in time on road to more features later. Nothing more, nothing less...

Getting to the Core of it

The take away from all of this is that the .NET platform on various devices and operating systems is becoming much more unified. It isn’t going to all happen before .NET Core and ASP.NET Core get released as version 1.0 at the end of the month. There will be additional and most likely incremental and non-breaking improvements after RTM that bring .NET Core closer to what’s in the current full framework BCL.

In the end this means you can build on .NET Core today, and expect more features to light up later, so things will get easier as time goes on. Whether you want to be an early adopter with the less featured framework now, or jump in later when more features have been added and the third party eco-system has caught up is going to be a (tough) decision that we all have to make on your own.

Regardless, I recommend taking ASP.NET Core and .NET Core for a spin. Build a sample app or a small to medium sized pet project and figure out how things work, what works and what doesn't. While a lot of things are similar there are lots of new things in .NET Core/ASP.NET Core that you either have to learn or at minimum get familiar with even if the concepts are not new to you. There's nothing like getting your hands dirty, instead of listening to guys like me ramble on about abstract shit like this :-)

What are your thoughts? Are you planning on using .NET Core and ASP.NET or are you planning on waiting for the 2.0 release, or are you going a different route altogether? Leave a comment below if you have thoughts.

Related Posts

Posted in ASP.NET  ASP.NET Core  

The Voices of Reason


 

Andrew Lock
June 13, 2016

# re: ASP.NET Core and .NET Core Overview

Very nice overview Rick, I think you really captured the optimistic but cautious atmosphere surrounding the .NET Core ecosystem.

I'm interested to hear that you don't rate ASP.NET Core over the full .NET Framework. To me there's a lot of benefits to be had with this setup, as you called out. Given that most .NET developers right now will, by necessity, be Windows developers, and that they will likely already have the required infrastructure in place for building and deploying any apps built using this combination.

For these developers the cross platform and the reduced footprint don't really come in to it - the full framework is already installed on their servers anyway. The only thing you are losing out on is the improved performance in the infrastructure (which, is diminished anyway once you are behind IIS).

Don't get me wrong, I love the benefits .NET Core brings (being able to develop .NET on my Mac with VS Code is really awesome) but to me ASP.NET Core is a great net framework on it's own. Building on top of the full framework seems like the obvious way to start using it ASAP don't you think? That way, you get to work with the new ASP.NET framework, while your class libraries can remain pretty much untouched.

Rick Strahl
June 13, 2016

# re: ASP.NET Core and .NET Core Overview

@Andrew - Great points.

I thought that too about full framework development a while back but after playing around with that for a while you start to realize that once you start down that road you're not easily going to go to Core later. The framework differences are subtle but actually very annoying to track down later which is in the end going to be almost the same as migrating from a MVC5/WebAPI app.

If you plan on going full framework and staying there, then using the full framework would be a good choice, but as a migration path I think you're not improving things much compared to running on the existing optimized for Windows full framework of .NET.

Also there are some things that don't work well even with full .NET - like old style configuration. I haven't tried this recently but even if you used full .NET System.Configuration etc. wasn't working which meant that a lot of stuff wasn't working even with full framework without quite a bit of tweaking.

We'll see how this plays out. I think the biggest reason I'm not so excited about the full framework support is that things will change and change quickly once the ball gets rolling and it's pretty clear where Microsoft will put its effort. I'm thinking .NET 1.x to 2.0 here - v1 was pretty rough where v2 added many important features (generics for one) and rounded out the platform with all the missing stuff they couldn't get into v1. I think we're looking at a parallel scenario. Using full framework on this stack will later on feel like using COM Interop in .NET me thinks :-)

Andrew Lock
June 13, 2016

# re: ASP.NET Core and .NET Core Overview

@Rick - that's interesting you had issues with System.Configuration. It's not that surprising I guess given the complete overhaul to config in ASP.NET Core, but probably exemplifies what you're referring to in terms of not being a great migration route.

I completely agree with you in terms of where Microsoft is going to put it's effort in, and the potential for v2. Exciting times! :)

Dani Calbet
June 14, 2016

# re: ASP.NET Core and .NET Core Overview

To help with these migrations issues I think it would be useful to have something similar to MoMa (http://www.mono-project.com/docs/tools+libraries/tools/moma/) that helped to found .NET > Mono migration issues. Do you know if something like that exists?

Chris Marisic
June 14, 2016

# re: ASP.NET Core and .NET Core Overview

I develop on Windows. I host on Windows. I don't see a single purpose of .NET Core. It really looks like .NET became frozen in time for the past 2 years that if it wasn't for the release of C# 6, this would have been a glaring void.

Maybe summer of 2018 there will be a compelling story. There isn't today, there won't be tomorrow. And there won't be anytime soon except perhaps if Nano Server requires .NET Core because they won't allow full installs of .NET inside of a Nano Server (i'd be shocked, but it's possible)

jdan
June 15, 2016

# re: ASP.NET Core and .NET Core Overview

The biggest issue I have currently is that I have an ASP.NET Core 1 RC2 site built against multiple projects that are .NET 4.5, and it builds perfectly fine on one machine, but when downloaded from Visual Studio Online the exact same code doesn't build. It just doesn't. I doubt there is any inherent code that prefers a SurfacePro 4 over a SurfaceBook, so I simply have a code base that works on (at least) one machine, but not on (at least) one other machine.

And this is going to RTM in 2 weeks. Swell.

Rick Strahl
June 16, 2016

# re: ASP.NET Core and .NET Core Overview

@jdan - you might want to post your use case as an issue to the GitHub tooling repo. It's hard to tell what you're trying to do exactly, but I have several projects that use .NET 4.5 dependencies and they work fine when moving between machines and pulled from GitHub repos. There might be some configuration or dependency management that isn't right, but I encourage you to reach out to the team and see what they say if this is something that's breaking you.

jdan
June 17, 2016

# re: ASP.NET Core and .NET Core Overview

It was significantly convoluted how I 'fixed' it, but it is related to the /wrap folder that got created on the machine that worked (when the project/site was created back when it was ASP.NET 5 MVC 6, or whatever). This is/was (not clear from GitHub) how .csproj files could work with the .xproj file, but isn't part of the solution per se (kind of like the /packages folder) so it doesn't make it into Visual Studio Online.

I discovered if I removed that folder, the working machine no longer worked, with build errors similar to the non-working machine. So eventually, I just copied over the directory structure exactly, and that got the not working machine working.

It still isn't clear to me if this /wrap folder is going away entirely, and there appear to be a number of people who are similarly 'blocked' with this issue, so where this is all going, I'm not sure.

FWIW

Kev
June 22, 2016

# re: ASP.NET Core and .NET Core Overview

Great article, it tackles the reality of dot net today! I'd like to point out that I think the "full framework mixin" is actually more appealing than you may think.

I believe a lot of companies are interested cross-platform ASP.NET which DNX showed a lot of promise before RC2. Some reasons include being open source friendly, licensing costs, licensing complexity, operational complexity and tooling. All of these are debatable, and I wouldn’t criticise Azure or the efforts made to improve the DevOps tooling for Windows, but developers need the choice. In fairness to Microsoft they are embracing choice and open source but we need dot net to progress now or risk losing to other ecosystems.

In docker we are now running a hybrid dotnet-cli/SDK - mono environment so we can target net45x and use critical dependant third party libraries for our MVC6 application. It is a bit of a mess but works for now.

Cross platform asp net really needs Kestrel and I think the dotnet-cli could be pulled back on top of mono but maybe that is just me.

It is also unclear what the removal of project.json actually means to the dotnet-cli tooling. In a year’s time no one will care if it is json/xml/xaml/yaml but first class nuget support makes dot net feel like a modern framework in an opensource world.

Regardless of if you call it ASP.NET Core does anyone else think MVC6 + Kestrel + dotnet-cli needs a (mono?) option to run net45x/net46x in docker?

Rick Strahl
June 23, 2016

# re: ASP.NET Core and .NET Core Overview

@Kev - I think Microsoft has been pretty clear that *their* goal for NET45/46 is the full framework *Windows* version. I think the Mono story in this is questionable going forward. I also seriously question that we'll need a full framework version of .NET that is cross platform - the main features that differentiate full framework today are its Windows integration features which really are useless for xplat development anyway. As pointed out we're not there yet because current .NET Core is limited, but according to Microsoft's plans (whatever that will actually turn out to be) we should get much closer to full framework BCL with .NET Core by V2. If that's the case then what does Mono really buy you *unless* you're porting an old application that has specific dependencies on Windows specific features that were ported by Mono to work on Linux?

In time I think we'll see .NET Core be the platform that can handle what full framework does today in a cross platform manner with third party (or Microsoft) add-on libraries providing the additional holes that aren't covered. In the long term I don't see Mono as something that will be necessary. If anything I see Microsoft merging Mono and Core into something more comprehensive under the Core moniker.

But - all conjecture at this point really, but this is what seems the logical progression of what Microsoft has proposed to this point.

Mike
August 15, 2016

# re: ASP.NET Core and .NET Core Overview

I am loving where dotnet core is going - stripping back dotnet and making a clean lean version of it.

But whats up with the project files?
is MS backing up and reverting to csproj files or staying the xproj course? - is the framework all changing again come core 1.x ?
the dot net core message seems to be very confused.

The lack of basic support and functionality for what is branded as a 1.0 release is very disconcerting.
So many people are having problems getting core to work meqaningfully is very little solutions beingf offered.
The biggest of all of them is an example that works with asp dotnet core and dotnet 4.5 libraries.

This is a basic necesity for me (or anyone else?) to do anything more than glorified hello world.

*hopping down off my soap box*

that said if anyone can point me to an example of how to use asp dotnet core with libraries and same solution projects that does not require an ugly hack,.. Please please! ;)

All of these future plans are great but if noone uses it, it looses mindshare along with relevence. :(
 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017