Well without the flag the code doesn't compile. And VS can't attach a debugger to a project that doesn't compile. So I have to add the flag with the project hook to be able to work with Noesis at all in VS. Also what exactly does the flag do? Check for Mono? Isn't that a bit bad anyway since Unity will soon also run with non-Mono runtimes? Is there anything you can do about that? maybe add that Project hook class to the Noesis package?

But you don't have to compile the project generated by Unity in VS, it is Unity who compiles the project anytime you change the scripts and come back to the editor.
You just need to attach your VS project to the running Unity instance using the "Attach to Unity" button.
That is the way we work here and we can debug the scripts without problem, but maybe I'm missing something.

About the mono flag is just there because we need to do a few things differently for mono. When Unity decides to switch to non-Mono runtimes we can simply delete that code as won't be used.

VS CANNOT attach to Unity if the code doesn't compile. I don't compile it, VS compiles it before attaching. If I don't use the project file hook to manually add the mono flag VS tells me "there were project errors, do you want to run the last successful build" and cannot attach to Unity.

As of now Noesis is unusable for me unless I add the flag manually to the project file using the VSTools ProjectFile creation hook. Without the flag all sorts of types are missing, like ICommand and others. Attaching to unity does NOT work right now.

I get a compiler error list of 33 errors for missing types, like ICommand, BondableCollection methods, Input, NotifyCollectionChangedAction, INotifyCollectionChanged...
Can't you use a different flag? Unity recommends different compiler flags for platform dependent compiling.

So just to confirm this, I opened a completely empty UnityProject, added the Noesis UnityPackage, then went in Unity on Assets->Open C# Project.
VS opens up, loads the project. I hit "Attach to Unity", and I get an message about build errors.
So I don't know how this works on your end but on mine this is unusable out of the box.

This is an important change in 1.3 because right now XAMLs are converted to Unity assets and Unity assets can only be used in you reference them from a Monobehaviour (or put them inside a /Resources/ folder). This is also important for building the standalone player. Unity needs to know what resources are needed. So, for LoadXaml(uri) and LoadComponent(urI) to properly properly you need the corresponding XAML being referenced on your project. The easiest way to do this is adding the desired XAMLs to the list inside Noesis Settings. Or you could have your own component in Unity referencing all the needed assets.

Sorry for the lack of documentation about this. We wanted to receive feedback before taking a decision about what's the best way to reference XAMLs used by custom user controls.

So just to confirm this, I opened a completely empty UnityProject, added the Noesis UnityPackage, then went in Unity on Assets->Open C# Project.
VS opens up, loads the project. I hit "Attach to Unity", and I get an message about build errors.
So I don't know how this works on your end but on mine this is unusable out of the box.

Strange, it seems Unity doesn't like SaveAssets() inside OnPostprocessAllAssets. Does it also happens in a clean project and editing one of the sample XAMLs included?

I'll test that later, but it certainly happened in several strange instances.

This is an important change in 1.3 because right now XAMLs are converted to Unity assets and Unity assets can only be used in you reference them from a Monobehaviour (or put them inside a /Resources/ folder). This is also important for building the standalone player. Unity needs to know what resources are needed. So, for LoadXaml(uri) and LoadComponent(urI) to properly properly you need the corresponding XAML being referenced on your project. The easiest way to do this is adding the desired XAMLs to the list inside Noesis Settings. Or you could have your own component in Unity referencing all the needed assets.

Sorry for the lack of documentation about this. We wanted to receive feedback before taking a decision about what's the best way to reference XAMLs used by custom user controls.

Hmm... adding it to the Noesis Settings worked. but I still think this is a bit weird. If it's referenced or loaded from the resources, why do I reference the path to the XAML file still in the LoadComponent call? I mean I'm not actually loading the xaml text file, I'm loading the asset file instead, aren't i? How does LoadComponent even do that lookup? After all the asset file could be somewhere completely different from the xaml file couldn't it? Also I don't really like having to hardcode a path since that breaks everything if I reorganize my project structure for some reason, like changing folders around or such. I guess this works for now but it would be cool if somehow it would be possible to implement an automatic lookup to link code behind and XAML. I mean the xaml contains the x:class attribute specifiying the type doesn't it? If I add it to the settings file as preloaded XAML could that type be used in a lookup table? Like when the code behind wants to load it, the Noesis framework looks in the preloaded stuff for a XAML that was stored under the correct type key?
Just an idea. For now that works thanks. once I added it to settings list (which I didn't even know existed ) it works fine.

The thing is just that because I saw in your sample code that the code behind referenced it by path, I thought that was enough. If you look at the samples it is absolutely NOT obvious that the used XAMLs are referenced by the settings. Maybe make the error message more clear to what the developer has to do to fix that? To me it was absolutely not obvious why the samples worked and mine didn't.

Debugging works here with Unity 5.5 and VS2015 without the __MonoCS__ symbol, despite the errors about the .NET 4.6 classes ObservableCollection, ICommand, etc.

Then i don't know why VS complains on my end, but even if it didn't, the errors are still annoying. After all intellisense is reporting problems all over the place, so is resharper. it would be impossible to figure out which errors are relevant and which are not.

On the positive side, adding the flag to Edit > ProjectSettings > Player > Scripting Define Symbols indeed solved the problem.
But I really think this should not be necessary and somehow should work out of the box without VS reporting errors all over the place. Doesn't Unity define any other compiler flag to the VS project that could be used for this check?

Edit: Btw, just in case that's ever needed by anybody. The way to hook into the project file creation I used to fix this previously was this:

Doesn't Unity define any other compiler flag to the VS project that could be used for this check?

Maybe !NET_4_6 found in the experimental Unity 5.6 with Mono Upgrade 4.6 preview, which has C# 6 language features and the .NET 4.6 classes (ObservableCollection, ICommand, etc). And you need to install a special version of VSTU for the correct project files. Noesis 1.3 crashes in it though.