INPC: dnxcore50 vs dnx451

Basically, I just cannot (well, I could not… see below) get the INotifyPropertyChanged / PropertyChanged thang to work using dnxcore50… but I can using dnx451. Now you might say that under Core, it never is going to work… but I can’t see a good reason why that is necessarily so.

Here is the dnxcore50/INPC combination not working – as I say there is the System.ComponentModel in DnxCore… but not one evidently that includes INPC:

Now, I change project.json to refer to Dnx451… and all is accepted in the code, and hovering points back to the right metadata:


Well, I couldn’t just let it lie could I? Browsing, I found this:

Fine, but it puzzles me that the package to include is System.ObjectModel, but it is still System.ComponentModel that is referenced in the code. But basically we’re working again. This implementation is obviously not finished, but that is not the aim of this:

DNX: 1 Caller, and 1 Callee


What and Why? The DNX examples I’ve done before have been standalone 1-line console apps. This is still a trivial-doesn’t-cover-it app, but it does introduce the hurdle of one class I wrote invoking another class I wrote, as opposed to NuGet-type dependencies. While there is some mention of global.json when googling how to do this principle, I see no need for that here. Indeed I failed to get an implementation working using global.json.

A total of 4 files was needed – two project.json files, each being the equivalent of a (full) Visual Studio project, and a .cs files in each of those projects.

I kept chopping out content from the project.json files, until they were the absolute minimum required.

Note this structure – at this point dnu has not been run, so there is no lock file. This is the Caller:



This is the structure for the Callee:


That is the entire codebase – note that there is no global.json or any other config, metadata file.

The content of the 4 files, viewed from VSCode. See how the code parser is not happy we have not yet run dnu:


We’ll click one Restore:


… and then the other:


, and all the squiggles are gone. Tick.

The code for each of the 4 files we wrote:


Note below that the Caller project.json declares a dependency on Callee. If the content of that yellow box is removed, then the execution breaks, because it can’t find Callee.




(oop – bit of inconsistency in naming…)



Finally the dnu command,


and the dnx command to execute the 2 WriteLines – 1 from the Caller, 1 from the Callee:



DNX: beyond Console.WriteLine()

Now I want to add in for example Generics. This is how my project.json looks right now:


And when in a file I use Generics, then possibly reasonably, as I haven’t specified them in the json, then I get squiggles:


Now maybe this is reasonable… but I thought there might be some cleverness that tried to discover what I was talking about (and remember, FWIW, I’m doing this in VS Code).

Let’s start to update the project.json, to see what Intellisense makes of this:


WAAH?! NonGeneric, Generic.RedBlack… let’s take a look at that:

Oh ok, like it says, forget NonGenerics

And the RedBlack thing? Let’s give it a try. OK, so it brought it down (of course):


Still doesn’t like it – doubtless doing something stupid, but let’s forget about RedBlack for now:


Continuing, let’s start to edit the 451 section of the json. The intellisense picked up dependencies… but could not find Generic. Cutting through, ,turns out this is the answer to the discovery thing:


And now it’s happy, or at least no squiggles on that one:


And in fact there is a perfectly good primer in this page… which I probably referenced before but forgot about, but it’s good to go through the issues yourself – that is how you learn.