Some questions about VS2015

[Sitten Spynne]

I'm going to supplment both (1) and (2) with some information that seems to slip some people's minds.

If you are using COM components, ActiveX, or 3rd party DLLs, you need to be prepared to potentially update your code or make some tweaks to your project. There are a few reasons.

One is I'm guessing you're moving to a new machine. When VS 2008 was new, it wasn't too uncommon to still have an x86 machine. .NET is versatile, and for a while defaulted to an AnyCPU setting that meant it would run as an x64 application when the machine could support it. We lost this useful default because COM and other not-.NET libraries are not that versatile, and if your application runs as x64 and tries to use an x86 DLL it will fail.

VS 2015 defaults to x86, which is the most safe option for backwards compatitiblity and guarantees Windows Desktop apps will get to keep behaving like it's 1994. But your project's probably already set to AnyCPU, that was the default for a while. Toggling it to x86 will likely "fix" any COM issues, unless you're already happily running on x64 machines. The better thing to do would be to find the 64-bit versions of your dependencies and dynamically load them from an AnyCPU assembly. But that's effort, and not a lot of people do it.

Similar problems exist with .NET DLLs: if you're using a third-party library, you have to match its CPU architecture or you're going to get weird runtime errors when they're loaded. So pay attention to your target CPU type, and be prepared to change it.

This part isn't "Why'd they botch .NET compatibility", this part is "Why wasn't Microsoft more aggressive about phasing out COM so we could adopt AnyCPU?" .NET was supposed to SOLVE these problems, not carry them forward into the future, but MS was a little to friendly for their own good.

Another potential problem is VS 2008 and VS 2015 use completely different runtimes. They're compatible, and can run on the same machine, but the older runtimes aren't installed by default on Windows 10. So you need to consider checking your project settings post-upgrade to see if it is targeting older versions, and decide what to do about that. This gets more agitating if you are using other .NET DLLs and they aren't built to run on the new runtime. You can mess with your App.Config file and *mostly* *sort of* *safely* tell it to deal, but it's still something you have to test.

That part is a bit of ".NET compatibility was poorly handled". Going forward it should be much better, as of 2013 or so they solved most of the terrible problems. But a disturbing majority still write code in VS 2010 or earlier, so we're going to be seeing these compatibility issues for decades. Lesson for yourself: always target the latest .NET Framework, and push back if you're asked to support an older one. This is impossible if you're dealing with a lot of older machines, which is a disturbing norm in our industry. At least make an effort.

But if you're not using COM/ActiveX, and your external dependencies aren't complex, it's painless. I can't think of any code changes you have to make to go from 2008 to 2015.