What am I supposed to do about "() Project Reference 'InsteonViewmodels' has no matching target (Echoes .NET) Insteon" error?

I still see build 2344 from Wednesday the 14th. Is that still the right one to download when you say “up”?

… never mind …

I see that the previous one didn’t include that (Nov 14). Must be the right one. Thanks.

Bummer, the new one failed the same way. I assume the (nov 14) overwrote the previous 2344 version since VS still shows it as just 2344.

I think I’ll try uninstalling and then reinstalling, just in case it didn’t like the same name (although the install of this latest one didn’t complain about anything during the install)

does it fail only in VS or ali’s when you build from the command line with ebuild? if. oh fail, dan you send me a detailed log from ebuild too? thanx!

Meantime, investigating the log:

		Version 10.0.0.2344 (develop) built on talax, 20181112-204643. Commit e79f74d.
		   Missing dependent project '..\ClassLibrary1\ClassLibrary1.elements' referenced from 'Insteon', but project path 'C:\Users\mtied\Documents\Visual Studio 2017\Projects\Insteon\ClassLibrary1\ClassLibrary1.elements' is valid.
		   -> Task RemObjects.EBuild.BuildSolution started.

so far so good.

		                     Project 'ClassLibrary1' referenced from 'Insteon' is not enabled, reusing cached final output.
		E:                   Project Reference 'ClassLibrary1' has no matching target (Echoes .NET)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets(53,3): error : Project Reference 'ClassLibrary1' has no matching target (Echoes .NET)

this looks like it’s not using my changes, though :(. also:

Version 10.0.0.2344 (develop) built on talax, 20181112-204643. Commit e79f74d.

this looks rather old, my change should be dated 20181114, this is from last week…

I totally uninstalled and reinstalled from the one listed in Personal Downloads as (nov 14)?

I only use VS and don’t know anything about “ebuild from command line”. How does one do that? How do I get a detailed log? Where is “ebuild”?

Now what?

… time passes …

I tried “ebuild” from command line and apparently it is in the path. Then I got current in the solution folder.

I did a “/?” to find out what the options might be.

I did “ebuild insteon.sln” and it said it compiled successfully.

… time passes …

I tried to redirect the output to a file to upload and there was almost nothing in the file (compared to what went to the console window). So I tried again. Now, no matter what I’ve tried so far, I only get the 4 or 5 lines of output at the console window. Nothing is ever easy. I’ll keep poking around a little more and see if I can get the original output again…

… time passes …

I keep getting “more than one project specified”, but the solution DOES have more than one project. Not sure why it didn’t complain about that the first time.

… time passes …

Oh, I was trying to specify verbosity and it must be taking that as another “project” name.

… time passes …

Oh, I thought the options were specified with “-”. Apparently “–” or “/” works. Here is the diagnostic output.

insteon.txt (23.7 KB)

Of course, the ebuild was successful so I assume there is nothing useful in there for you, but maybe there is.

So at least we know the problem is something with Visual Studio, it looks like to me anyway.

from the log, the ebuild on the command line is the new one, that has my fix. i have no idea how VS could still be running the old version, but that is why it’s not working there for you…

Not sure how I got an old one in there, but I just deleted the old installer, uninstalled the current version, reinstalled the (nov 14) again. I checked when the uninstall happened that all the remobjects files were gone and they were.

I just tried a build again, and it worked. Not sure why it failed last time. Maybe my mouse slipped when I opened up the installer before. Oh well, it works now.

Thanks.

… time passes …

Crap. No, I think it was because I just added the new project but maybe I didn’t put the reference. Checking it out more to let you know what is going on now…

… time passes …

Nope. Same problem. Ebuild is happy, visual studio 2017 complains about echoes. I even added Echoes manually to the new InsteonViewmodels project.

Severity	Code	Description	Project	File	Line	Suppression State
Error		() Project Reference 'InsteonViewmodels' has no matching target (Echoes .NET)	Insteon	C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.targets	53	

now what? Did you actually try the build in VS 2017 when you made your changes? Or did you just make it work in Ebuild? I think I’ll try it in Water…

Worked fine in Water (which of course uses Ebuild). So I’m guessing this is some sort of msbuild problem? Or does VS use Ebuild now?

… next day …

I see that Ebuild IS being used in Visual Studio. (The output window seems to have a lot more information in it now. Not sure why. Perhaps because I did a Water compile?)

… time passes …

Interestingly, after compiling in Water successfully, a new Build operation in Visual Studio is ALSO successful.
Even a “Clean” in VS followed by a “Build Solution” still works.

Is that a clue why VS doesn’t work initially? Is there something that Water does to the solution or project or something that might be fixing VS?

At least I seem to have a work around now. I can compile in Water and then keep working in VS.

1 Like

I’m getting this problem in two of my projects. I’m using version 10.0.0.2343 of Silver for Visual Studio.

I’ve figured out some workarounds, after spending many hours of trial-and-error changing .elements files and .csproj files.

In one case, I had to remove the reference to the project’s GUID like this:
< !-- < Project>{d224bfff-8897-47ef-a960-351f67e60f3c}< /Project> -->

In other cases, specifying a hint path for the referenced module that seemed to help.

So then I got one project solution working fine.

Then for my second project, I encountered the same bug. My tricks didn’t work, I gave up and re-installed an old version of rem objects. I’m looking forward to this being fixed.

Probably the same bug then, given this was fixed after .2343. Can you try latest, .2345?

Mark_Currie,

Were you able to do the trick I did? Just compile it in Water? Then go back and try in VS?

Thanks for the suggestion mtiede

@mh, I’m having a hard time upgrading my project to the version of Silver where collections are treated as value types. I’m using the C# Mongo Driver and in order to make it work, it seems I need to convert collections to C# collections for all objects stored in MongoDB. It’s a tedious process. So I think I’ll stay on the older version until I get the courage to upgrade. But it’s good to know there’s already a fix for my original issue.

Mark,

can i recommend mchangjng to using different types, eg List instead of [T] where interop with platform native lists is important?

Yes, I’ll do that. It’s great that you guys made Swift collections to be more like official Swift, I appreciate that. I’ll get past these upgrade issues soon enough. Thanks.

1 Like

I tried .2345 and it didn’t complain about Echoes. However, it complained about missing NewtonSoft.Json. I tried to go to the packages and add that package, but it said it was already installed. Long story short, I had to do a clean build on the new project and uninstall and reinstall the package before things were cleaned up.

I don’t know if that is enough information to help you, but bottom line, it DOESN’T complain about Echoes anymore.

Are the packages and references used by the files that were copied to the new project SUPPOSED to copy all the necessary things to the new project for the references automatically?

… time passes …

Oh crap. I spoke too soon. Although adding them to the new project didn’t complain, when I then added the reference to that project to the main one, it DID still complain.

Sorry I spoke too soon. I had forgotten what the sequence was that caused the problem in the first place.

… time passes …

Recompiling with Water still fixes the Echoes reference problem for VS.

K, so same issue as in the other thread then. I’ll need to compare what a broken and a good build look like.