It seems to be resolved, when will it be available?
bugs://E27359 was reopened.
If it had actually been resolved it would have been in todayâs upcoming build, but i am afraid this was a false alarm and we havent found the issue yet. IDK why my colleague close the ticket, must have been by accident.
As it stands, we still have no idea why this is happening. MSBuild just kills the external proces that runs the actual compile in the middle of things; debugging this i see none of our code running, itâs all in MSBuild :(.
This kind of stuff is why we gave up on using pure MSBuild for regular Elements projects, forever ago, and created EBuild. Ofc that doesnât help you if you need other MSBuild-based targets includedâŚ
Assuming this is a new issue for you â what was the last version where this worked okay for you, before.3013? Suffice to say nothing really has changed in this specifc code in forever (itâs called the Legacy.targets file for a reason), but who knows, maybe knowing that will help us narrow this downâŚ
I had Visual Studio 17.12.x installed with elements 12.0.0.2991, and everything was working reasonably well. But Visual Studio started popping up messages saying that this version was no longer supported and that I should update. After updating, the problem started, and I decided to update to the latest version of elements, assuming that would solve it.
The thing is, it works really badly and itâs torture to work in these conditions.
And thatâs it.
Curious. that is really not that long ago. This may give us a chance to narrow it down by divide-and-conquer maybe to see when it broke, and thus with what change.
Iâll look at that after some additional ideas for testes/debugging i have, that iâll be pursuing today and over the weekend. As soon as i have a solution, i will keep you posted.
Until then, is maybe going back to 2991 a reasonable compromise, at least until we sort this out? Probably not much changed btween that and 3013 that affects you for ASP.NET devâŚ
Againm i apologize for the inconvenience,
thanx,
marc
Can you try this:
- open
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\RemObjects Software\Elements\RemObjects.Elements.Echoes.Legacy.targets(or whatever else your log file tells you is the exact location that this file is being read from). Note: there might/will be multiple copies on disk, so dont just search for it and fix the fiest one you find ;). - find any occurences of
TaskFactory="TaskHostFactory(there should be two, near the top) - remove the attribute
- save the file
- build again (note, VS might cache .targets files; best to close and restart).
If that alone doesnt work, try replacing the entire file with the one attached, then oen the file to replace â__VERSION__â with your exact version number (e.g. â12.0.0.3113â).
__RemObjects.Elements.Echoes.Legacy.targets.zip (4.0 KB)
But try the fist steps first, if possible.
(.3019 will not have that fix yet, as that build is off an running already, for today)
Remove TaskFactory=âTaskHostFactoryâ or the whole line?
Answered my own question, remove only TaskFactory=âTaskHostFactoryâ seems to work. Need to grant permissions for both the directory and the file.
1 Like
Happy to hear! the fix is in for next weeks build.
Sorry for being imprecise; as you found, yes, just the one attribute; itâs what caused the task to run out-of-process, and thatâs somehow broken. Nothing here changed on our side in ages (years, st least), so my assumtion is that something changed with a new VS or MSBuild update that trigegrs the bug.
Perfect, everything seems to be working.
Thank you, Mark.
