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:

Later…

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:

Advertisements

DNX: 1 Caller, and 1 Callee

Caller07

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:

 

Caller01

This is the structure for the Callee:

Caller02

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:


Caller03

We’ll click one Restore:

Caller04

… and then the other:

Caller05

, and all the squiggles are gone. Tick.

The code for each of the 4 files we wrote:

Caller

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.


Caller06

Caller07

Callee

(oop – bit of inconsistency in naming…)


Caller08

Caller09

Finally the dnu command,

Caller10

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

Caller11

 

DNX: beyond Console.WriteLine()

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

composer01

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

composer05

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:

composer06

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):

composer07

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

composer08

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:

composer09

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

composer10

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.