I don't know what could be happening in your project different from what we are testing here.
Anyway, as having all these Intellisense errors in VS is not desirable, I think it is safe if we use ENABLE_MONO and ENABLE_IL2CPP defines.
We will add them in the next release like this:
#if __MonoCS__ || ENABLE_MONO || ENABLE_IL2CPP
namespace System.Collections.Specialized
{
/// <summary>
/// A collection implementing this interface will notify listeners of dynamic changes,
/// e.g. when items get added and removed or the whole list is refreshed.
/// </summary>
public interface INotifyCollectionChanged { ... }
}
#endif
Thank you. I checked again in VS, the errors I'm getting are not intellisense errors. They are clearly build errors. On "Attach to Unity" VS is starting a build process. It's probably not really building an assembly, but it's checking whether the code compiles anyway. And it reports build errors. I filtered all Intellisense errors out of the output window, since you can filter intellisense and build errors there. All the 'missing type' errors and such are Build output errors. I don't know WHY VS is doing it on my end and not on yours, but quite honestly I like my version a lot better. It SHOULD report errors if the code doesn't work. And without the flag it clearly doesn't work. It's weird that there are different flags set in the VS project and in the Unity compiler but the __MonoCS__ flag is probably set by the Mono Runtime, not by Unity. So I think adding the ENABLE_MONO check is the safer bet for unity. That seems to be the flag they support for the IDE code projects.
As I said I have no idea what could be different. I literally tested it with a clean Unity project, just adding your package, nothing else, then telling Unity to open VS. So there's NO other code than yours in the project and VS cannot attach.
For adding the __MonoCS__ flag manually in the Unity project generation settings to fixes the problem, just in case someone else needs the workaround for now.
Btw, sometimes it IS desirable to build the code in VS, just to be able to run a separate unit test project against the output assembly. Yes one could also use the one Unity produces, but some people precompile DLLs and put those into the assets folder. I've seen people discuss this workflow in the forums, even though it seems not the desirable way to do things in Unity. If anybody every did that including the Noesis code, that wouldn't work without the flag. So it's definitly a thing that needs to be fixed like this.
Looking forward to the next version.