locked
Ifdef in Javascript?

    General discussion

  • Just out of curious. 

    Is there anything like 

    #ifdef DEBUG
    ...
    #else
    ...
    #endif

    for Javascript in Visual Studio 11?

    So the answers from @phil_ke and @Kraig are NO. Kraig would like to see suggestions. So I changed the original question to a discussion. 

    Thanks,


    Louis


    • Changed type Louis_PiG Tuesday, February 07, 2012 7:59 PM Open for suggestion as suggested by Kraig
    • Edited by Louis_PiG Tuesday, February 07, 2012 8:00 PM
    Tuesday, February 07, 2012 5:16 PM

All replies

  • I don't think so. There is no preprocessor for JS integrated into VS.
    Tuesday, February 07, 2012 5:59 PM
  • It would be nice, but unfortunately there isn't such a capability. #ifdef only works for conditional compilation, but JavaScript is more of a JIT compiler/interpreter so it doesn't have a way to include some code and not other. This means that you have to use if statements against a global variable or some other trick for debug code. If others have good recommendations, I'd like to see them on this thread!

    .Kraig

    Tuesday, February 07, 2012 6:02 PM
  • Debug.debuggerEnabled is as close as you can come as far as I can find.

    http://msdn.microsoft.com/en-us/library/windows/apps/hh969516(v=vs.94).aspx

    Wednesday, October 31, 2012 3:36 AM
  • The workaround I've been using is to check the package installation path and look for "Debug" in the folder name.

    I wrote a post a few weeks ago detailing this:

    Detect DEBUG build configuration via JavaScript in Windows Store apps
    http://caioproiete.net/en/detect-debug-build-configuration-via-javascript-in-windows-store-apps/


    I also put a NuGet package available to make it easier to use this approach:

    JavaScript Debug Symbols for WinRT
    https://nuget.org/packages/WinRT-JsDebugSymbols/1.0.0


    Cheers,
    Caio Proiete

     


    Caio Proiete
    Microsoft MVP, MCT, MCPD, MCTS, MCSD
    http://caioproiete.net



    Monday, November 05, 2012 2:50 AM
  • It's still a pain to use the Windows.ApplicationModel.Store.CurrentAppSimulator class. Why was this implementation detail not completely hidden from the developer? The developer always uses one API Windows.ApplicationModel.Store.CurrentApp that internally switches behaviour depending on how the app was deployed. If the relese/debug version was deployed via VS/PowerShell script then the Simulator for the App Store is used internally and if the app was installed from the store the real store is queried.

    Why put this burden on the developer in the first place? The wwahost already knows beforehand how the app was deployed.

    Come on MS... you had the unique chance to rebuild the Windows API for the future and now such things. And the only answer (even during this years //build/) is that you MUST NOT FORGET TO CHANGE Windows.ApplicationModel.Store.CurrentAppSimulator to Windows.ApplicationModel.Store.CurrentApp before you build the store package. Hell, I hope the WACK warns you in case you forgot about this minor detail.

    Monday, November 05, 2012 12:57 PM