0

I just updated to Visual Studio 2017 Profesional. When I create a no-frills WPF app and start it up in debug, Visual Studio spins for a while and then stops, reporting that the application existed with a code of 0. No window is ever shown. The constructor on the App class is never called.

What is going on? I'm switching back to Visual Studio 2013 in the meantime, but I'd like to get this figured out.

For those of you who voted to close this question, here is how you reproduce:

  1. Launch Visual Studio 2017.
  2. Click File -> New Project.
  3. Select "WPF App (.NET Framework)".
  4. Click OK.
  5. DO NOT CHANGE ANYTHING AT ALL!
  6. Click Start on the Standard toolbar.

After step 4, that is my MCVE. What else do you want?

Jordan
  • 9,642
  • 10
  • 71
  • 141
  • I'm assuming this has happened repeatedly. Have you tried repairing your installation? – xtreampb Jun 26 '18 at 17:10
  • Please post your App.xaml markup and App.xaml.cs codebehind – Cam Bruce Jun 26 '18 at 17:10
  • I just updated Visual Studio. I have to restart before I try it though. My App.xaml and App.xaml.cs won't help you. It is boilerplate. – Jordan Jun 26 '18 at 17:19
  • It sounds like the main loop is not running the form. – theMayer Jun 26 '18 at 17:20
  • Might be an issue with it finding files linked together (it divides the app into partial files which it links at compile time). – theMayer Jun 26 '18 at 17:21
  • This is bizzare. I changed the build configuration from Any CPU to x64, and now it works. When I try x86, I get the same bug. This is not ideal but it is a work around. I'm going to want to build it as Any CPU. – Jordan Jun 26 '18 at 19:06
  • 1
    Yeah, the debugger does not run unless the build configuration is set to x64. That is the problem. – Jordan Jun 26 '18 at 20:42
  • 1
    This is most assuredly a Visual Studio 2017 configuration issue. It seems it is rare but has happened [here](https://stackoverflow.com/questions/29356236/visual-studio-unable-to-use-debugger-accessviolationexception-code-executing) as well. I don't have an answer at the moment, but I find that the 'work around' of setting the platform target to x64 is unacceptable. – Adam Vincent Jun 27 '18 at 19:40
  • Just for funsies, I would try VS 2017 Community Edition to see if it has the same issue. If so, I would venture a guess that 'upgrading' and having VS 2013 and VS 2017 installed side by side might be causing the issue. – Adam Vincent Jun 27 '18 at 19:46
  • Well, by upgrade, I mean that I installed Visual Studio 2017. – Jordan Jun 27 '18 at 20:35

0 Answers0