Weird VS2022 ide error

[2kaud]

I have a weird VS2022 (17.6.5 under Windows 7) C++ ide error. If I make any code changes and then try to save the solution or build the solution I get the error "Could not load file or assembly Microsoft.visualstudio.validation, version = 17.8.0. The system cannot find the file specified".

However the Compile option works OK and then I can use Save and also Build OK afterwards. But if I then make a code change Build/Save again fail and I have to use Compile before Build. Also using the Clean Solution enables Save and Build to work OK until a code change then the error occurs again......

I cannot update VS2022 to a later version as 17.6.5 is the last version that works with Windows 7.

Why is VS trying to use validation version 17.8.0 when I'm using 17.6.5???

Please does anyone have any ideas about this?

Thanks.

[yereverluvinuncleber]

Could Microsoft update have attempted to upgrade a component automatically?

P.S. I have auto updates turned off and blocked from re-enabling by WUB.

[2kaud]

Windows updates are done manually after a notification message. However MS doesn't now issue any updates for Windows 7 as it's long out of support. The only updates installed lately are for Windows Defender Antivirus.

PS. Turning off Windows Defender Antivirus has no effect on this issue.

PPS I've tried the repair option, but this just tries to first download/install the latest build which isn't supported with Windows 7 so just displays an error and exits. It won't attempt to repair the installed version. Ahhhh.....

[fafalone]

VS2022 is a bloated monstrosity I've never seen without major bugs even on fully up to date systems. I have to click through errors every launch even after a clean install following a clean install of Windows itself.

If you can still build what you need to build, just leave it alone, it will only get worse.

[2kaud]

If you can still build what you need to build, just leave it alone, it will only get worse.

That's what I'm doing. Compiling from the command line using cl is fine - if I can get the compiler/linker options right! And as I said from within the IDE I can first compile/clean and then build as 2 steps rather than 1. I can live with that as compile will auto save any changes. I just wondered if anyone else had had this problem and anything they did to fix it.

Is anyone else here using VS2022 with Windows 7 for any language?

VS2022 is a bloated monstrosity

Yep. I've looked at the later versions of VS2022 to what I'm using and it's getting worse! IMO MS should bring out a cut-down IDE without all the 'bloat' that fully supports the languages/frameworks etc with the debugger.

[2kaud]

For info. VS2019 works OK on the same computer.

The surprising thing is that compiling with VS2022 using the v143 toolset gives the compiled .exe size as 347,648. However when I compile the exact same source files with VS2019 (v142 toolset) or the v142 toolset with VS2022, I get an .exe size of 333,312. Go figure!

[PlausiblyDamp]

For info. VS2019 works OK on the same computer.

The surprising thing is that compiling with VS2022 using the v143 toolset gives the compiled .exe size as 347,648. However when I compile the exact same source files with VS2019 (v142 toolset) or the v142 toolset with VS2022, I get an .exe size of 333,312. Go figure!

That could be down to different optimisations or code generation in the newer tooling.

[2kaud]

That could be down to different optimisations or code generation in the newer tooling.

The compiler settings for both the toolsets are the same. Both VS2019 and VS2022 using the v142 toolset generate the same sized code.

[PlausiblyDamp]

The compiler settings for both the toolsets are the same. Both VS2019 and VS2022 using the v142 toolset generate the same sized code.

So presumably v143 toolset is doing different optimisations and code generation.

[fafalone]

Yeah and beyond optimizations there's actually a lot of hidden stuff like secret entry points and security mitigations that it inserts into your exe/dll by default that only increases over the years. It's been a real pain for debugging why things compiled by MSBuild work but the same essential code compiled in tB doesn't when the entry point you specify in settings isn't even the entry point it uses, and the one it makes is entirely undocumented and closed source.