WPF/Visual studio/debugging

[yamangman]

Got an WPF application loading platform(x86/64 at any rate)-agnostic libs. Problem is when targeting Any CPU platform, the autogen vshost debug helper has 32bitreq flag set according to corflags. Now I could script ilasm to unset this, but surely I'm missing something? Visual studio isn't this dumb is it? The runtime exe does not set 32bitreq as I'd fully expect while targeting Any CPU, much as I'd expect the vshost to do the same.

tl;dr
Why does visual studio set 32bitreq on vshost helper when targeting Any CPU?

[Optimaximal]

Are you targeting a particular version of .NET? Also, what version of VS? Different versions handle AnyCPU slightly differently - one VB project fell on its arse when ported to VS2013 from 2008 because of changes to the AnyCPU definition between .NET 3.5 and .NET 4+

[TheAnimus]

Probably a bit late for this, but I think you are confusing what the vshost is.

It's not really a 'debug helper' more a restarting the process helper. Starting and stopping processes is expensive, so vhost can help with that. However compared to the compilation cost and such, it's really not worth it, just turn it off.

All processes have to be either 64 or 32bit. You can not be both in one process. This will be decided at start up for an Any CPU project, which has the corflags set as such.

[yamangman]

Debug helper, restarting the process helper, tomato tomato.

I guess re-reading the question it is less than legible. The question was, why does the vshost executable have 32bitreq on AnyCPU and the artifact binaries do not?

[TheAnimus]

Because of how the vhost works is the short answer, it is an un-managed process, so can not be any CPU.

If this worries you, you can just select in VS csproj area, not to use it. To be honest, I don't normally bother with it, it's an out-dated problem.

[Steve Works]

That should solve the problem..I guess.

[TheAnimus]

The other solution is to make your vhost be the right process version, you can do this from the csproj settings again, but you would probably be better off adding another profile, so you've got Debug and Debug64 etc.

However, depending on the kind of library you are making, it shouldn't be an issue at all. It only matters when you start doing pinvoke stuff using libraries that are x86/x86 specific.