Ok, I'm in a world of pain at the moment.
We'd been developing with VS2008 (VB.NET, mostly WinForms, also ASP.NET and Windows services) on Win7 x64, with specific requirements (that we can't get rid of yet), to target x86 and framework 3.5.
We recently upgraded to VS2010, and quite soon, fell foul of this ResGen.exe incompatibility issue. Basically, we can't compile the WinForms app at all with VS2010. None of the workarounds suggested by Microsoft or others have worked for either myself or the other member of my team.
So we attempted to revert to VS2008 using the technique described here (ie hack the solution file), and also by creating a brand new VS2008 solution, and adding the projects to it. This seemed fine for a short while, but now we discover that when debugging the application, unhandled exceptions are not caught in the IDE, which makes development virtually impossible.
A brand new test application created with VS2008 (compiled for x86 and .NET 3.5) does not exhibit this failure to catch exceptions.
I've had to resort to developing on VS2010 on a Win7 (32 bit) VM inside the main computer for now, and it does work... but it's slowwwwwwww!
Any ideas for a way out of this would be gratefully appreciated!!
Update:
Ok, so it's not an actual solution, but as a workaround it's not a complete disaster...
Thanks to Noah for his comment, which prompted me to explore the various virtualisation solutions around. I've now discovered (probably the last person here!) VirtualBox. Not only is it quite a bit slicker in use than VMWare Player and the various incarnations of Microsoft/Windows Virtual PC, it also has Seamless mode, where apps running on the VM appear as separate windows in the host. So I now have an x86 guest running VS2010, compiling for x86 and Framework 3.5. Since there's no x64/x86 conflict in the guest, there's no Resgen.exe problem, and my dev envt just appears as a window on my host desktop. It's still slower than running it natively would be, but I can live with it for now.
Would still appreciate any actual solutions (or, failing that, a fix from Microsoft!!)